Good suggestion. This could be helpful for sparse slow requests. We could discuss the detail of the strategy here :)

Any thoughts? (maybe combine with concurrency control?)

Could you give me more informations about it?
I am confused about sparse slow requests and concurrency control because I can not associate them with my issuse.

IMHO, the PR #1490 seems did not fix this issue.

The main point of problem is thatWhether the Sentinel circuit breaker can cut off the traffic when it know inflight entries will trigger the breaker finally,instead of all unexpected slow entries exit

At some implementations such as hystrix , another thread will perform some fallback work when a actual working thread does not return after a timeout. With the current structure of Sentinel, it is not suitable to achieve a similar implementations, but some designs can be used to achieve the same effect：

1. the sample count of SlowRequestLeapArray should be calculated by maxAllowedRt/statIntervalMs, and the window length should be setted as statIntervalMs.
2. SlowRequestCounter should count inflight entries and track predecessor deprecated bucket after reset().
3. tryPass() should increment total, inflight, slow counter, and each new window should check prev inflight request once.
4. onRequestComplete() should decrement inflight and slow counter optionally, when that is slow entry, it also check current window.

I will try to work on it, any other thoughts? ;-)