Allow policy registries to be defined for keys of any type

Is your feature request related to a specific problem? Or an existing feature? Please describe. Currently the PolicyRegistry class is tied to string keys, as opposed to being generic on the key. The result is that it’s not possible to create a PolicyRegistry with a different type as the key.

For example, if I want to key my policies by System.Uri, the only option I have is to implement IConcurrentPolicyRegistry<Uri> - which makes no sense because I don’t want or need any different semantics from what PolicyRegistry does, I just want it to allow me to use a different key type. I also don’t see anything on PolicyRegistry that is string-specific.

Describe your proposed or preferred solution:

• Rename the current PolicyRegistry to KeyedPolicyRegistry<TKey>. Create a “new” PolicyRegistry class that inherits it, i.e. PolicyRegistry : KeyedPolicyRegistry<string>.

(Ideally we’d change PolicyRegistry to PolicyRegistry<TKey> and create a StringPolicyRegistry : PolicyRegistry<string>, except that would be a breaking change.)

• PollyServiceCollectionExtensions should get 2 new generic overloads of AddPolicyRegistry that allow specifying the key type of the policy implementation. These will use KeyedPolicyRegistry<TKey>.

• PollyHttpClientBuilderExtensions should get 3 new generic overloads of AddPolicyHandlerFromRegistry that handle the generic key scenario.

Describe any alternative options you’ve considered: Unending pain and torment, AKA implementing IConcurrentPolicyRegistry myself, registering a generic version of it myself, et cetera.

Any additional info? Nope.

[martintmk]

Yes, V8 now supports this scenario.

[IanKemp]

It’s so nice to interact with someone who is passionate about the project and willing to take time to address/answer questions, no matter how daft they may be. @martincostello you are an exemplar of how interactions on GitHub should be - really, thank you. I wish I could say that my interactions with actual MS employees had generally been this helpful but alas…

(I also totally didn’t forget that generic types are not considered the same as non-generic types with the same name, despite doing .NET for over 15 years at this point. I swear I’m not getting old and forgetful…)

Anyhow, it sounds like you broadly agree with my proposal, so what’re the next steps? Do I need to write up a formal doc like dotnet/runtime requires, or does the Polly team need to discuss it further, or…? The reason I ask is that I’d be happy to contrib the code for this (to both Polly and ASP.NET Core) as it doesn’t appear to be a huge change in terms of effort, but obviously I’m not gonna do anything until you guys give the go-ahead.