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

[buckleyGI]

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]

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.

[github-actions]

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.