HedgingStrategyOptions
Configures the hedging resilience strategy.Properties
The maximum waiting time before spawning a new hedged action.Special values:
TimeSpan.Zero: Create all hedged actions at onceTimeout.InfiniteTimeSpan: Never create a new action before the old one finishes
DelayGenerator for greater control over hedging delays.The maximum number of hedged actions to use, in addition to the original action.
- Must be between 1 and 10
- Default is 1
A predicate that determines whether hedging should be executed for a given outcome.Default: Hedges on any exception except
OperationCanceledException.ActionGenerator
Func<HedgingActionGeneratorArguments<TResult>, Func<ValueTask<Outcome<TResult>>>?>
required
A generator that creates hedged actions.Default: Executes the original callback that was passed to the hedging resilience strategy.
A generator that produces hedging delays for each hedged action.The
DelayGenerator takes precedence over Delay. If specified, Delay is ignored.An event raised when hedging is performed.Hedging is executed when:
- The current attempt outcome is not successful and
ShouldHandlereturnstrue, OR - The current attempt did not finish within the
Delay
Extension Methods
Add hedging strategies to a resilience pipeline:OnHedgingArguments
Arguments passed to theOnHedging callback.
- PrimaryContext: The context received by the hedging strategy
- ActionContext: A cloned context used for the hedged action
- AttemptNumber: The zero-based hedging attempt number
Usage Examples
Basic Hedging
Hedging with Multiple Endpoints
Dynamic Hedging Delays
Conditional Hedging
How Hedging Works
- The primary action starts executing
- If the action doesn’t complete within
Delay(or doesn’t succeed):- A hedged action is spawned in parallel
- This continues up to
MaxHedgedAttemptsadditional actions - The first successful result is returned
- Remaining actions are cancelled
- Reducing tail latency
- Improving reliability when multiple redundant services are available
- Load balancing across multiple endpoints