Polly icon indicating copy to clipboard operation
Polly copied to clipboard

[Feature request]: Update CircuitBreaker with the possibility to hold requests on it instead of rejecting immediately when CB is opened

Open h4wk13 opened this issue 9 months ago • 4 comments

Is your feature request related to a specific problem? Or an existing feature?

CircuitBreaker currently rejects all requests that are going through when it's opened.

Describe the solution you'd like

Hold requests for a configurable (?) amount of time instead.

Additional context

No response

h4wk13 avatar Apr 16 '25 10:04 h4wk13

You can achieve this with a combination of circuit breaker and retry. The retry should wait until the circuit breaker enters into the HalfOpen/Closed state. We have documented somewhat similar under this pattern: Using different sleep duration between retry attempts based on Circuit Breaker state

peter-csala avatar Apr 16 '25 14:04 peter-csala

Yeah, I know that, but it means that the timings of both must be synchronized, meaning, retry policy has to "know" about how much time breaker will be opened because it will use all its attempts to retry CB exceptions. which means I need more than one waitandretry, which means longer and more complicated policy,

h4wk13 avatar Apr 17 '25 05:04 h4wk13

Hey @h4wk13 , I'm currently on spring holiday. I will reply to your concern on the week of 28th April.

peter-csala avatar Apr 22 '25 10:04 peter-csala

Quite frankly I'm unaware of any Circuit Breaker implementation which does support this kind of queueing mechanism.

Other resilience libraries provide just slightly different capabilities:

  • Resilience4j provides a bit more customization options how to calculate the failure rate
  • FailSafe allows you to define two kinds of CB: time or count based
  • Hystrix differentiates multiple error kinds: timed out, rejected, and failed
  • etc.

I have seen a rate limiter implementation which uses queueing. It is called rate gate because it is proactively holding back requests to do not violate the request rate.

So, the suggested way is to use a combination of strategies to achieve the desired behavior.

peter-csala avatar Apr 28 '25 07:04 peter-csala

This issue is stale because it has been open for 60 days with no activity. It will be automatically closed in 14 days if no further updates are made.

github-actions[bot] avatar Jun 28 '25 02:06 github-actions[bot]

This issue was closed because it has been inactive for 14 days since being marked as stale.

github-actions[bot] avatar Jul 12 '25 02:07 github-actions[bot]