Demonstrate how to create dynamic strategies with complex keys

[martintmk]

Details on the issue fix or feature implementation

This sample demonstrates how to define a HTTP resilience strategy that is created and configured for different combinations of endpoints/resources.

The idea is to cache the strategy by complex EndpointKey. This sample also demonstrates how EndpointKey can be used to create dynamic strategies where some inner strategies are conditional.

Paired with the EndpointKey is the configuration of ResilienceStrategyRegistryOptions<EndpointKey> where we customize how the registry creates and caches the strategies.

@martincostello

Contributes to #1365

Confirm the following

• I started this PR by branching from the head of the default branch
• I have targeted the PR to merge into the default branch
• I have included unit tests for the issue/feature
• I have successfully run a local build

[codecov]

Codecov Report

Merging #1366 (1275507) into main (8bb251a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #1366   +/-   ##
=======================================
  Coverage   83.80%   83.80%           
=======================================
  Files         273      273           
  Lines        6476     6476           
  Branches     1010     1010           
=======================================
  Hits         5427     5427           
  Misses        840      840           
  Partials      209      209           

Flag	Coverage Δ
linux	?
macos	83.80% <ø> (ø)
windows	83.80% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

[martincostello]

Thanks for this - I'll have a play around with it now.

In my case, these options objects are bound from IConfiguration via DI, so they observe configuration changes. In this way of doing things, how would they observe changes? With the code I already have, we explicitly just clear the policy registry when the configuration changes and then policies are then rebuilt from scratch to account for any configuration change.

[martincostello]

Off the top of my head, would nulling out the ResilienceStrategyProvider<T> and then just recreating it from the service provider as a transient solve that?

[martincostello]

It's also getting a bit bootstrap-y, as I need the options from configuration to configure the service container, as that's where the endpoint options come from.

[martincostello]

This is starting to get a bit complicated - tomorrow I'll try and extract the relevant parts of the v7 Polly code into a runnable-sample with the existing tests - then it'll be easier to see what the migration path would be and if there's anything we can do to make that easier.

[martintmk]

@martincostello

In my case, these options objects are bound from IConfiguration via DI, so they observe configuration changes. In this way of doing things, how would they observe changes?

In case you configure the EndpointOptions in DI the sample can be simplified. Instead of including it in the key you can just resolve those from DI and use it to configure resilience strategy. Additionally, you can instruct Polly to dynamically reload the resilience strategies when these options are changed.

Instead of:

var endpointOptions = context.StrategyKey.EndpointOptions;

You do:

// resolve the options from DI
var endpointOptions = context.GetOptions<EndpointOptions>(context.StrategyKey.EndpointName);

// enable dynamic reload of the resilience strategy being configured whenever the named options are changed
context.EnableReloads<EndpointOptions>(context.StrategyKey.EndpointName);

[martintmk]

@martincostello is it OK to merge this one or we are waiting for alpha.6?

[martincostello]

Sure - btw have you forgotten to re-open Slack since your vacation? 😄

[martintmk]

Sure - btw have you forgotten to re-open Slack since your vacation? 😄

Ooops, I check it maybe once, twice a day so the risk of me missing something is high :D