Introducing custom Polly policies and Polly.Contrib (Custom policies Part I)
Introducing custom policies
The Polly team have long wanted to allow users to extend Polly's capability with custom policies.
Polly v7.0 introduces a simple mechanism for authoring custom policies which integrate fully with the existing Polly architecture: the fault-handling syntax, the execution overloads, and the ability to combine policies in a
This article introduces custom policies and the Polly.Contrib. If you're just interested in the how, skip straight to:
- Part II: Authoring a non-reactive custom policy (a policy which acts on all executions)
- Part III: Authoring a reactive custom policy (a policy which react to faults).
- Part IV: Custom policies for all execution types: sync and async, generic and non-generic.
Why custom policies?
There were three drivers for introducing custom policies to Polly:
1. To allow users to write any custom Policy
Custom policies allow you to use
PolicyWrap as a generalised execution-dispatch wrapper - your custom Policy can act as middleware for any execution.
There is no limit to what custom policies can do (we don't impose a structure) - a new policy could add extra information, capture extra information, intervene in how the passed code actually executes (as many Polly policies do), schedule execution in a new way ...
2. To start a Polly.Contrib
Sometimes ideas for features can't immediately be built into Polly because of time constraints; or because an idea falls outside the core focus of Polly.
Polly.Contrib provides a freer environment in which policies can be contributed and explored by users and the Polly team, with a lower decision threshold and burden of ceremony.
The Polly team is kick-starting the Polly.Contrib with:
- blank templates for authoring your own custom policy
- a policy to capture execution timings
- a policy simply to log exceptions/faults and rethrow.
If you'd like your custom policy to be part of Polly.Contrib, contact us on Polly slack, we'll have some brief discussion to understand the intent and where the policy fits, then we can set up a Polly.Contrib repo - to which you have full rights - to help you manage and deliver your awesomeness to the Polly community!
3. To deliver new functionality outside the main Polly package (..."Welcome Simmy!")
Simmy is a major new package from the Polly team and some awesome contributors @mebjas and @vany0114, which opens a path for chaos-engineering and fault injection using Polly. It's aimed at both live-testing the resilience of your production systems; and simulating faults in the unit testing or CI phase.
As a fault-injection tool, Simmy has a different focus to Polly, and we wanted to host the new concept in a package with its own name and identity.
To learn how to author your first custom policy, skip straight to: