[Feature request]: Allow setting the retry attempt

[BalassaMarton]

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

The problem I'm facing is that I'm using a Polly retry strategy for running a retriable action, but in a durable way: I'm storing the number of previous attempts, and the process can exit in the middle of the Nth attempt. When that happens, and execution resumes in a different process, I want to be able to run the same resiliency pipeline, but tell it to start from attempt N so that a recurring error that might crash the process doesn't make the pipeline start from the first attempt every time and go into an infinite retry loop.

Describe the solution you'd like

The cheapest solution would be to add an optional property to RetryStrategyOptions:

    public ResiliencePropertyKey<uint>? CurrentAttemptPropertyKey { get; set; }

When this property is set on the context, RetryResilienceStrategy should read the attempt number from this property instead of initializing it to 0.

Additional context

No response

[martincostello]

From a quick scan of this, while we could do this from a technical perspective, it sounds like a use-case (resilient out-of-process retries) that Polly isn't designed for (why try to retry at all if you already know there's only one attempt left when you configure the policy?) so I don't think it makes sense to actually add.

[BalassaMarton]

why try to retry at all if you already know there's only one attempt left when you configure the policy

I don't. Isn't the whole point of defining policies that you create the policy once and then reuse the pipeline on a whole class of work done by the app? In this case, I'm incrementing a persistent counter on each attempt, but the resiliency pipeline is preconfigured.

[martincostello]

Retries are usually configured once as a re-usable instance across the service/context and then re-used across individual operations. For example, you have a retry policy/strategy for all HTTP requests (say, retry 5 times), then each individual HTTP request does retries using that policy but each invocation gets 5 retries.

As described, I interpreted your use case to be "a specific operation has already been retried once, so I want that specific retry to account for the ones already done out-of-process". In that scenario, it wouldn't make any sense to configure all retries to account for that one retried operation, and on a per-operation basis (otherwise all requests would retry 5-{used} times, not just the specific instance of an operation being retries). If you already know you've only got 1 attempt left, then there's no point in configuring a retry policy at all because it's just overhead.

In this case, I'm incrementing a persistent counter on each attempt, but the resiliency pipeline is preconfigured.

If you already know the persistent count, why not create the policy to reduce the retry count by the number you know have already been used? Pseudocode:

var retries = 5;
var alreadyTried = database.GetAlreadyTriedCount();

if (retries < 1)
{
    // None left
    return DoTheThing();
}
else
{
    var options = new RetryStrategyOptions()
    {
        MaxRetryAttempts = retries - alreadyTried,
    };

    var pipeline = new ResiliencePipelineBuilder().AddRetry(options).Build();
    return pipeline.Execute(DoTheThing);
}

If I'm not understanding what you're actually asking for, then please provide a much more detailed description of the specific problem you're trying to solve with code showing what you'd want to do in the context of how you're using Polly today.

[BalassaMarton]

@cschanhniem I did this already, the main problem is not being able to break out from the retry loop, but that everything inside the Polly retry logic assumes that the first attempt in this invocation is the first attempt ever, and that matters when doing exponential backoff in an otherwise infinite retry loop. Sure, I could implement my own delay logic, but it would be more conventient to just pass the known attempt number to the pipeline.

[BalassaMarton]

@cschanhniem no. The current attempt number can't be a part of the strategy descriptor since it is something that varies between executions of the same strategy. Another variation of the feature would be to add a few extension methods to ResilienceContext:

/// <summary>
///   Extension methods for <see cref="ResilienceContext"/> to store and retrieve properties related to the Retry strategy.
/// </summary>
public static class ResilienceContextRetryExtensions
{
    internal static readonly ResiliencePropertyKey<uint> AttemptNumberPropertyKey = new("Retry.AttemptNumber");

    /// <summary>
    /// Gets the current attempt number from the <see cref="ResilienceContext"/> (starting with <c>0</c> for the first attempt).
    /// </summary>
    /// <param name="context">The <see cref="ResilienceContext"/> instance.</param>
    /// <returns>The current attempt number.</returns>
    public static uint GetAttemptNumber(this ResilienceContext context) =>
        context.Properties.TryGetValue(AttemptNumberPropertyKey, out var value)
            ? value
            : 0;

    /// <summary>
    /// Sets the attempt number in the <see cref="ResilienceContext"/>.
    /// </summary>
    /// <param name="context">The <see cref="ResilienceContext"/> instance.</param>
    /// <param name="attemptNumber">The attempt number to set.</param>
    /// <remarks>
    /// Application code can use this method to set the initial attempt number when executing a retry strategy.
    /// The strategy will update the attempt number on each retry, and it can be retrieved using <see cref="GetAttemptNumber"/>.
    /// The strategy will overwrite the attempt number on each retry, so any value set inside callbacks may be lost or cause inconsistent behavior.
    /// </remarks>
    public static void SetAttemptNumber(this ResilienceContext context, uint attemptNumber) =>
        context.Properties.Set(AttemptNumberPropertyKey, attemptNumber);
}

In this case, the strategy will just read the attempt number at the beginning of the retry loop, and also update it on each iteration.

[BalassaMarton]

I submitted a PR with the second option