nanjiek opened a new issue, #869: URL: https://github.com/apache/dubbo-go-pixiu/issues/869
### ✅ Verification Checklist - [x] 🔍 I have searched the [existing issues](https://github.com/apache/dubbo-go-pixiu/issues) and confirmed this is not a duplicate ### 🚀 Go Version 1.25.0 ### 📦 Dubbo-go-pixiu Version 1.1.0 ### 🖥️ Server Configuration _No response_ ### 💻 Client Configuration _No response_ ### 🌐 Protocol Configuration _No response_ ### 📋 Registry Configuration _No response_ ### 💾 Operating System 🪟 Windows ### 📝 Bug Description The current implementation of HTTPCircuitBreakerFilter in pkg/filter/circuitbreaker/circuitbreaker.go is incomplete. While it correctly integrates the Sentinel entry check, it lacks the feedback loop (error and latency reporting) to the Sentinel core. As a result, the Sentinel circuit breaker state machine will always perceive requests as successful and instantaneous, meaning the circuit breaker will never transition to the OPEN state, regardless of how many 5xx errors or slow responses occur in the actual backend service. ### 🔄 Steps to Reproduce 1.Configure HTTPCircuitBreakerFilter in conf.yaml with a specific resource and a circuit breaker rule (e.g., Strategy: ErrorRatio, Threshold: 0.1). 2.Point the backend service to an endpoint that consistently returns 500 Internal Server Error or has a high latency. 3.Send multiple requests through the Pixiu gateway to this endpoint. 4.Check the Sentinel logs or observe the gateway behavior. ### ✅ Expected Behavior When the backend service's error ratio or slow call ratio exceeds the configured threshold, Sentinel should transition the resource state to Open. Subsequent requests should be blocked by sentinel.Entry and return a 503 Service Unavailable response locally from the gateway until the circuit breaker enters the Half-Open state. ### ❌ Actual Behavior The gateway continues to forward all requests to the failing backend service indefinitely. Even if the backend is 100% down, the circuit breaker never trips because` entry.SetError(err) `or `entry.SetSlowRequest(true)` is never called to provide the necessary statistics to the Sentinel state machine. ### 💡 Possible Solution The filter needs to capture the result of the backend invocation. Since Decode happens before the request is proxied, we should: Extend the filter to implement the` Encode` (post-processing) phase or use a defer mechanism to capture the final context state. Check` ctx.BackendError` or the response status code. If it indicates a failure (e.g., 5xx), call `entry.SetError(err)`. Calculate the latency of the backend call and call `entry.SetSlowRequest(true) `if it exceeds the threshold. Ensure `entry.Exit() `is called only after these statistics are reported. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
