Using Configuration to Setup Polly

I’ve written the following extension method to help me configure Polly from my ASP.NET Core JSON configuration file. It may help others if something more complete was included in Polly itself.

Policy policy = Policy.Handle<Exception>().FromOptions(options);

public class PolicyOptions
{
    public TimeSpan? DurationOfBreak { get; set; }

    public int? ExceptionsAllowedBeforeBreaking { get; set; }

    public int? RetryCount { get; set; }

    public bool RetryForever { get; set; }
}

public static Policy FromOptions(this PolicyBuilder policyBuilder, PolicyOptions options)
{
    if (policyBuilder == null)
    {
        throw new ArgumentNullException(nameof(policyBuilder));
    }

    if (options == null)
    {
        throw new ArgumentNullException(nameof(options));
    }

    Policy policy;
    if (options.RetryCount.HasValue)
    {
        policy = policyBuilder.RetryAsync(options.RetryCount.Value);
    }
    else if (options.RetryForever)
    {
        policy = policyBuilder.RetryForeverAsync();
    }
    else if (options.DurationOfBreak.HasValue && options.ExceptionsAllowedBeforeBreaking.HasValue)
    {
        policy = policyBuilder.CircuitBreakerAsync(options.ExceptionsAllowedBeforeBreaking.Value, options.DurationOfBreak.Value);
    }
    else
    {
        throw new ArgumentException(
            $"Invalid Policy Options.",
            nameof(options));
    }

    return policy;
}

[reisenberger]

Pinging on this thread, to alert that there is a lot of related discussion going on in the ASP.NET Core 2.1 HttpClientFactory repo around the Polly integration.

[reisenberger]

Triage: Closing this issue as not something the core Polly team is likely to add.

Back when this issue was proposed, it made a lot of sense, as Polly had only two policies, configured in mostly-numeric ways.

Polly now offers a wider range of policies, and a range of more powerful ways of configuring them:

• some policies such as Fallback are entirely non-numeric
• most policies which in their original versions were entirely numeric now also take more function-driven overloads: retry policy can take an IEnumerable<TimeSpan> of delays-before-retrying; or alternatively a Func<outcome, TimeSpan> to drive retry delays from 429 responses; TimeoutPolicy a Func<TimeSpan> timeout; circuit-breaker will soon take a Func<int, TimeSpan> function to calculate breakDuration.

TL;DR A config-constant-driven Options-API for Polly now would inevitably end up covering only a fragmented subset of ways of configuring policies. This makes it make less sense for the Polly team to aim to provide as an API alternative. However, it is still fairly easy for users to implement for themselves (and a great approach), for a particular subset of constant-driven Polly features they use.