Introduce Hedging Strategy

We are working on the development of a generic HedgingPolicy to use as part of our HttpClient Resilience pipeline. Since the hedging as a policy is not yet supported by Polly we consider setting up a new package dedicated to the generic implementation of such policy. Please let us know if you are interested in having this and how we could proceed further.

Summary The hedging policy will allow the sequential and delayed execution of a set of tasks, until one of them completes successfully or until all of them are completed. First task that is successfully completed triggers the cancellation and disposal of all other tasks and/or adjacent allocated resources.

General structure of polly policy:

• The Async<PolicyName>Syntax exposes extension method for the PolicyBuilder which builds new instances of the Async<PolicyName>:
  • e.g. for Hedging: AsyncHedgingSyntax exposes methods to create AsyncHedgingPolicy instances.
• The generic Async<PolicyName>Policy is the actual policy, which:
  • Inherits the AsyncPolicy<TResult> base class
  • Exposes internal constructor and it is created only via the Async<PolicyName>Syntax extensions.
  • Implements the abstract method of the base class, Async<PolicyName>Syntax which contains the actual implementation, i.e.

    Task<TResult> ImplementationAsync(
        Func<Context, CancellationToken, Task<TResult>> action,
        Context context, 
        CancellationToken cancellationToken,
        bool continueOnCapturedContext)
    

    • e.g. for Hedging: AsyncHedgingPolicy

---

Hedging policy configuration

The base implementation will take:

• HedgingDelay - how long shall one wait before spawning a new hedged request;
• OnHedgingAsync - task performed after every spawning a hedged request; [can be used for logging & telemetry]
• A list of hedgedTaskFunctions - the tasks performed via hedging if the primary execution delegate fails.

---

Hedging logic

Steps:

1. Start executing task [first one first]
2. Wait up to HedgingDelay ms
3. If the request is:

• A. Completed:
  • If result is an exception
    • If ShouldHandleException - GOTO [B]
    • else - GOTO [4.]
  • If result is not exception
    • If ShouldHandleResult - GOTO [B]
    • else - GOTO [4.] (e.g. result is successful, so return result).
• B. Not Completed:
  • Next task will be executed - GOTO [1.]

1. The result of the execution can be:

• [Success]
  • First request to complete successfully triggers the cancellation of all others
  • Return successful result.
• [Failure]
  • No request completed successfully, and all requests have been executed.
  • Return the failure of the first task.

---

Exposed API for policy creation:

 var hedgingPolicy = Policy
                .Handle<Exception>()
                .OrResult<string>(_ => false)
                .AsyncHedgingPolicy(
                    hedgedTaskFunctions,
                    defaultHedgingDelay,
                    onHedgingAsync);

[joelhulen]

I have no objections, either. In fact, I find that any contrib project migrating to core is a win 😃

[martintmk]

The hedging will be adopted directly in Polly.Core for V8. The API will be adjusted to conform to v8 shape.

• Options based
• Hedging extensions for ResilienceStrategyBuilder