[FEATURE REQ] RetryPolicy / RetryOptions - configurable exponent & random boundaries and/or custom retry mode (user provided CalculateExponentialDelay)

[ohads-MSFT]

Library name

Azure.Core

Please describe the feature.

Consider the existing method for calculating exponential backoff delay:

azure-sdk-for-net/sdk/core/Azure.Core/src/Pipeline/RetryPolicy.cs

Line 331 in 4d8a097

(1 << (attempted - 1)) * _random.Next((int)(_delay.TotalMilliseconds * 0.8), (int)(_delay.TotalMilliseconds * 1.2)),

As you can see, the following are hard-coded:

1. Exponent 1 << basically means Math.Pow(2, attempt - 1) (so it's set to 2)
2. Lower random boundary (0.8)
3. Upper random boundary (1.2)

The exponent especially can be critical to the resulting delay time series, but since exposing all the above seems very simple (basically add 3 properties to RetryOptions), might as well add them too.

In addition, a RetryMode.Custom could be added which allows setting a custom-provided CalculateExponentialDelay. I suppose if we have this kind of extensibility then parametrizing the above properties won't be strictly needed, but IMHO it would be nice to have all the same (e.g. the Azure.Core team might improve the method yet retain the constants used, for example guard better against overflow).

[jsquire]

//cc: @christothes, @annelo-msft

[jsquire]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[christothes]

Hi @ohads-MSFT As of version 1.27.0 It is possible to implement a custom retry policy with a customized CalculateNextDelay.

Does this work for your scenario?

[ohads-MSFT]

Hi @christothes

I'm probably missing something, but it looks like RetryPolicy is internal:

azure-sdk-for-net/sdk/core/Azure.Core/src/Pipeline/RetryPolicy.cs

Line 17 in 0275433

internal abstract class RetryPolicy : HttpPipelinePolicy

Seems like this was intentional per the following comment from @JoshLove-msft: #33281 (comment)

Making it public again would go a long way towards this feature request, though it would still require clients to reimplement the logic in CalculateNextDelayInternal (specifically the server delay override). Not a huge deal to be sure, but I maintain that the suggestions I've made above would be a bit more convenient.