polly-contrib / polly.contrib.waitandretry Goto Github PK

In the readme here: https://github.com/Polly-Contrib/Polly.Contrib.WaitAndRetry/blob/master/README.md?plain=1

I found this:

var delay = Backoff.ExponentialBackoff(TimeSpan.FromMilliseconds(100), retryCount: 5, factor: 4);

It goes on to say:

The upper for this retry with a growth factor of four is 25,600ms. Care and a calculator should be used when changing the factor.

I eventually built this out in a spreadsheet because care a calculator wasn't working. ;) Shouldn't the sequence be:

1: 100ms
2: 1600ms
3: 8100ms
4: 25600ms
5: 62500ms (TL;DR: 100ms * 5 ^ 4)

...Making the upper 62,500ms? Please let me know if this is calculated differently.

In any event, keep up the great work!

I read (and sort of understood) the genesis of this lib over on Polly #530. I love love that all of that jitter work has found its own home. But, when I click through on the nuget badge to https://www.nuget.org/packages/Polly.Contrib.WaitAndRetry, I get an oops page. Since there's nothing in the search, I assume this package isn't currently published? What is the recommended consumption model?

I am trying to implement the policy with DecorrelatedJitterBackoffV2 method:

private static void SetPolicies()
{
var delay = Backoff.DecorrelatedJitterBackoffV2(medianFirstRetryDelay: TimeSpan.FromSeconds(1), retryCount: 5);
_policy = Policy.Handle().WaitAndRetryForeverAsync(retryAttempt => TimeSpan.FromMilliseconds(Math.Pow(2, retryAttempt)),
(exception, timespan, context) =>
{
Log.Information( exception.Message);
});
}

But it has no been possible to include the delay because of the number of attempts. I mean, i need to use the delay generated in the method WaitAndRetryForeverAsync. is it possible?

Thanks in advance.

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

Similar to existing feature.

Describe your proposed or preferred solution:

Expose a new backoff strategy, in this package, similar to Backoff.DecorrelatedJitterV2.cs but that does not include the exponential aspect in the returned sleep durations.

Describe any alternative options you've considered:

A naive implementation:

public static IEnumerable<TimeSpan> ConstantJitterBackoff(TimeSpan averageDelay, int retryCount, double jitterFactor = 0.5)
{
    for (var i = 0; i < retryCount; i++)
    {
        // Calculate random jitter
        var jitter = ((Random.Shared.NextDouble() * 2) - 1) * jitterFactor;

        // Apply jitter factor to the averageDelay
        var delayWithJitter = TimeSpan.FromTicks((long)(averageDelay.Ticks * (1 + jitter)));

        yield return delayWithJitter;
    }
}

Any additional info?

This would be useful for scenarios where we want to retry with some randomness but always around a specific interval.

Add ReadMe documentation. It should ideally cover:

• the package overall purpose
• syntax example for each backoff strategy

( Example readme - not perfect - sure it can also be done better 🙂 )

Summary:

Given that DecorrelatedJitterBackoffV2 uses takes the median of the inital delay, I had expected that the sum of all delay times would sometimes be higher than the sum of all delay times generated by ExponentialBackoff. This does not seem to be the case. Maybe I am misunderstanding? Can we be guaranteed that the sum of the DecorrelatedJitterBackoffV2 delays will always be less than the sum of the ExponentialBackoff delays?

I want to know as I am trying to understand the maximum amount of time that an operation could take including timeouts, delays and retries.

Here are the inputs:

initialDelay: 300ms
retryCount: 3

First generate a list of delays using ExponentialBackoff. Sum the total of all of these delays. (2,100ms)
Next generate lists of delays using DecorrelatedJitterBackoffV2. Sum the total of all of these delays and compare to the sum from ExponentialBackoff.

Expected behavior:

Sometimes the sum of the delays generated by DecorrelatedJitterBackoffV2 is greater than the sum of the delays generated by ExponentialBackoff.

Actual behaviour:

The sum of the delays generated by DecorrelatedJitterBackoffV2 is never greater than the sum of the delays generated by ExponentialBackoff.

Not essential but: the template has been updated to simplify the build and add SourceLink support

Polly-Contrib/Polly.Contrib.BlankTemplate#7

Could impose same here

Get the initial project structure in place, with the basic code & units working too.

George Polevoy has given permission for the algorithm to be included here.

Summary:
Currently when using Discord Bots sometimes the sockets get into an invalid state, however it is most of the time frequently in about every few hours.

Expected behavior:

For the socket to not go into invalid state ('Aborted') and instead go into CloseSent so that way WebSocketException is not thrown.

Actual behaviour:

Transient error in gateway client: The WebSocket is in an invalid state ('Aborted') for this operation. Valid states are: 'Open, CloseSent'
System.Net.WebSockets.WebSocketException (0x80004005): The WebSocket is in an invalid state ('Aborted') for this operation. Valid states are: 'Open, CloseSent'
   at System.Net.WebSockets.WebSocketValidate.ThrowIfInvalidState(WebSocketState currentState, Boolean isDisposed, WebSocketState[] validStates)
   at System.Net.WebSockets.ManagedWebSocket.ReceiveAsync(ArraySegment`1 buffer, CancellationToken cancellationToken)
--- End of stack trace from previous location ---
   at Polly.Retry.AsyncRetryEngine.ImplementationAsync[TResult](Func`3 action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates`1 shouldRetryResultPredicates, Func`5 onRetryAsync, Int32 permittedRetryCount, IEnumerable`1 sleepDurationsEnumerable, Func`4 sleepDurationProvider, Boolean continueOnCapturedContext)
   at Polly.AsyncPolicy`1.ExecuteAsync(Func`3 action, Context context, CancellationToken cancellationToken, Boolean continueOnCapturedContext)
   at Remora.Discord.Gateway.Transport.WebSocketPayloadTransportService.ReceivePayloadAsync(CancellationToken ct)
   at Remora.Discord.Gateway.Transport.WebSocketPayloadTransportService.ReceivePayloadAsync(CancellationToken ct)
   at Remora.Discord.Gateway.DiscordGatewayClient.GatewayReceiverAsync(CancellationToken disconnectRequested)

Steps / Code to reproduce the problem:

I sadly personally never used WaitAndRetry myself but I think Asking @Nihlus for example code that can reproduce it can help narrow down the cause.

Same issue as: Polly-Contrib/Simmy#56

Set up the build system & policies

Is your feature request related to a specific problem? Or an existing feature? Please describe.
My request is related to a warning I get when using the nuget package ina strong named assembly - "Referenced assembly 'Polly.Contrib.WaitAndRetry, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name.".


Describe your proposed or preferred solution:
Sign the assembly.


Describe any alternative options you've considered:
Create another nuget package with strong name.

Polly.Contrib binaries target Framework 4.7.2, but this excludes assemblies Framework 4.7.

Solution: Add Framework 4.7 to the list of targets:

We want to log retries and 'giving up' with its own message.
I now implemented this with a condition in the Retry:
if (attempt < MaxAttempts) {normal behavior} else {custom log message}
with MaxAttempts one higher than the actual number of attempts.

I'm not sure what the most elegant solution would be. Maybe a fluent method like GiveUpWith() after Retry?

When using DecorrelatedJitterBackoffV2 with a large number of retries (i.e. 50), the formula starts returning negative TimeSpans. This is due to the prev value being larger than next.

Expected behavior:
DecorrelatedJitterBackoffV2 should never return an negative TimeSpan

Actual behaviour:
DecorrelatedJitterBackoffV2 returns a negative TimeSpan after a large number of retries

Steps / Code to reproduce the problem:
See the following c# fiddle for steps to reproduce:
https://dotnetfiddle.net/fAWqnz

The existing build is liable to this issue seen in other Polly builds: App-vNext/Polly#737