search

App-vNext / Polly

Polly is a .NET resilience and transient-fault-handling library that allows developers to express policies such as Retry, Circuit Breaker, Timeout, Bulkhead Isolation, and Fallback in a fluent and thread-safe manner. From version 6.0.1, Polly targets .NET Standard 1.1 and 2.0+.
https://www.thepollyproject.org
BSD 3-Clause "New" or "Revised" License
13.43k stars 1.23k forks source link

[Question]: Are retry budget as described in this excellent article #2348

Open buckleyGI opened 3 weeks ago

buckleyGI commented 3 weeks ago

What are you wanting to achieve?

In this Good Retry, Bad Retry: An Incident Story the strategy of "Retry budget" is described Retry budget (or adaptive retry): Retries are always allowed, but within a budget, for example, no more than 10% of the number of successful requests. In case of service problems, it can receive no more than 10% of additional traffic.

Reading the polly documentation it's not clear that this is present out of the box or can be achieved with combing some of the primitives. It's a great read that article!

What code or approach do you have so far?

Circuit breaker but it's an all or nothing strategy, not configurable as with Retry Budget.

Additional context

No response

martincostello commented 3 weeks ago

We don't have Retry Budget as a first-class concept for retries (in fact I've not heard of that as a specific term before).

The concept sounds like a hybrid of our retry, circuit-breaking (the ability to track successful vs. failed operations) and rate-limiting (capping the total throughput) in terms of the strategies we provide.

I'm not sure there would be an easy way to implement this with the library as-is today with our existing strategies without reimplementing/refactoring a lot of the state tracking used by circuit breakers to control whether or not do do retries based on some global state tracking the success vs. failure rate and the overall throughput.