Fork me on GitHub

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 PolicyWrap.

This article introduces custom policies and the Polly.Contrib. If you're just interested in the how, skip straight to:

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 the community has more ideas for features than the core Polly maintainers have time to build! As well as accepting PRs into Polly, we want to give the community easier ways to explore and author add-ons to Polly - be that cache providers, syntax additions, or custom policies which can integrate with all the goodness of the existing Polly execution dispatch.

The Polly team is kick-starting the Polly.Contrib with:

  • blank templates for authoring your own custom policy - these ready-made repos integrate to the latest Polly and have built-in build-script packaging to nuget
  • an example custom policy to capture execution timings
  • an example custom policy simply to log exceptions/faults and rethrow.

To get going, simply fork/duplicate one of the blank templates and code away!

If you'd like your custom policy to be part of Polly.Contrib, that'd be awesome (in fact we actively encourage it!). Bringing your custom policy (or other contribution) into the Polly-Contrib gives you:

  • exposure and recognition under the Polly brand
  • in-built CI (AppVeyor) which builds to nuget packages
  • ability to publish the nugets under the Polly-Contrib organisation
  • involvement in a wider team who can support and advise.

Contact us on Polly slack to move your contrib into Polly-Contrib and we can help organise delivering 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 @vany0114 and @mebjas. Simmy 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.

Where next?

To learn how to author your first custom policy, skip straight to:

Author image
United Kingdom Website
Dylan is the lead contributor and architect on Polly, and the brains behind the roadmap, which is seeing Polly growing into the most robust, flexible and fully-featured resilience library for .NET!