DEV Community: Paul Arun Prasath

Polly's maintenance fee starts 16 November. Is your .NET app affected?

Paul Arun Prasath — Mon, 02 Nov 2026 12:22:31 +0000

Check your solution in one command, along with MediatR, AutoMapper, MassTransit and FluentAssertions.

On 14 July 2026 the Polly project announced that it's adopting the Open Source Maintenance Fee (OSMF). Payment requests start on 16 November 2026.

Polly is everywhere in .NET. The Polly package alone has more than 1.7 billion downloads, and Microsoft's own resilience packages are built on it. So the question many teams are asking right now is simple: do we have to pay?

For most teams the answer is no, but it depends on two details that are easy to miss. In this post I'll explain both, then show how to check every project in your solution in one command.

What actually changes

Here's what the Polly announcement says, quoted directly:

Price and threshold: "The Maintenance Fee is US $20 per month and applies to any company that earns at least US $20,000 from at least one product or project that uses Polly."
Which versions: "The fee applies only to the next major version of Polly released after November 16, 2026." And: "Existing versions of Polly are not subject to the fee."
Which references: "Only direct references to Polly are subject to the fee. If Polly is a dependency of a different library, such as Microsoft.Extensions.Resilience or Microsoft.Extensions.Http.Resilience, the fee does not apply."

The source code stays open under its existing BSD-3-Clause licence. Individuals, students, hobbyists and organisations below the revenue threshold don't pay.

The two details that decide whether you're affected

1. Version. Polly 8.x, which is what you're almost certainly using today, is not affected. The fee applies to the next major version (Polly 9) released after 16 November. So upgrading carelessly is the real risk, especially with Dependabot, Renovate or a casual dotnet add package Polly.

2. Direct vs transitive. If you only get Polly through Microsoft's resilience packages, the fee doesn't apply. A typical example is AddStandardResilienceHandler() from Microsoft.Extensions.Http.Resilience. Your app still loads Polly.Core, but you don't reference it yourself.

Both are hard to see by eye in a real solution:

Using statements don't tell you. The official OSMF guidance warns about this itself: using Polly; compiles whether Polly comes in directly or through another package.
References hide in many places. They can be in Directory.Build.props, in Directory.Packages.props with Central Package Management, or in one test project nobody looks at.
Licence scanners won't flag it. Polly's licence label stays BSD-3-Clause, so tools that compare licences against an allowed list see nothing unusual.

The OSMF website's advice for .NET is to open every .csproj, collect the package references and check each one by hand.

Check it in one command

" width="800" height="400">

I built a small open-source tool for exactly this: PackageTerms. It reads the restore output NuGet already produces (obj/project.assets.json), so it sees the exact versions your projects resolve, including transitive ones, and tells you which packages changed their terms.

dotnet tool install -g PackageTerms
package-terms scan MySolution.sln

Here's a sample solution with an API project and a test project:

Scanned 2 project(s).

[COMMERCIAL] MediatR 13.1.0 (direct)
  From v13, MediatR is dual-licensed under RPL-1.5 and the Lucky Penny Software commercial licence. Earlier versions keep their original Apache-2.0 terms.
  Last free version: 12.5.0
  Alternative: Mediator.SourceGenerator: Source-generated mediator by Martin Othamar (MIT).
  Projects: Shop.Api.csproj

[COMMERCIAL] MediatR 13.1.0 (transitive via Shop.Api (project))
  ...
  Projects: Shop.Tests.csproj

[UPGRADE RISK] Polly 8.9.0 (direct)
  Your version is still free, but Polly 9.0.0 and later carries a maintenance fee (from 2026-11-16). Check the terms before upgrading.
  Who pays: Companies earning at least US$20,000 from a product or project that uses Polly: US$20 per month. Direct references only; Polly brought in by another library (for example Microsoft.Extensions.Http.Resilience) is exempt.
  Projects: Shop.Api.csproj

And here's a project that only uses Microsoft's resilience package:

[NO ACTION] Polly.Core 8.4.2 (transitive via Microsoft.Extensions.Http.Resilience → Microsoft.Extensions.Resilience → Polly.Extensions)
  Polly's new terms cover direct references only, so this transitive reference is exempt.

For each package, the output tells you three things:

Are you affected? It shows your exact version and whether the reference is direct, or the chain of packages or projects it comes through.
What changed and when, with a link to the official announcement.
What to do: the last free version and free alternatives.

It's not just Polly

Polly is the newest change, but several popular .NET libraries changed their terms in the last two years. PackageTerms checks these too:

Package	What changed	Covered versions	Last free version
Polly	Maintenance fee, direct references only	9.0 and later	8.x
MediatR	Commercial licence (free Community edition under US$5M revenue)	13.0 and later	12.5.0
AutoMapper	Commercial licence (free Community edition under US$5M revenue)	15.0 and later	14.0.0
MassTransit	Commercial (Massient licence)	9.0 and later	8.5.12
FluentAssertions	Paid licence for commercial use (Xceed)	8.0 and later	7.2.2

Every entry links to the project's own announcement or licence, and the data is open on GitHub. If you know of a package that's missing, please open an issue with a link to the official source.

Catch it in CI, before it reaches main

Upgrades usually arrive through automated pull requests. Add one step to your pipeline and the build fails if an affected package slips in:

- run: dotnet tool install -g PackageTerms
- run: package-terms scan --fail-on affected

Use --fail-on upgrade-risk to be stricter, or --format markdown to post the result as a pull-request comment.

What to do if you are affected

Polly, direct reference, organisation above US$20K revenue: stay on Polly 8.x (it's not subject to the fee), budget US$20 per month when you move to Polly 9, or use Microsoft.Extensions.Http.Resilience for HTTP resilience, which brings in Polly transitively and is exempt.
MediatR, AutoMapper, MassTransit, FluentAssertions: check whether you qualify for a free tier, buy a licence, pin to the last free version, or move to an alternative such as Mediator.SourceGenerator, Mapperly, Rebus or Shouldly.

Whatever you decide, decide it deliberately rather than finding out from an automated upgrade.

Try it

Install: dotnet tool install -g PackageTerms
Source and dataset: https://github.com/paulap887/PackageTerms
Polly announcement: https://thepollyproject.org/2026/07/14/polly-osmf-announcement.html

paulap887 / PackageTerms

Find NuGet dependencies that went commercial or added a maintenance fee (Polly, MediatR, AutoMapper, MassTransit, FluentAssertions). A dotnet tool.

PackageTerms

Find the NuGet packages in your .NET solution that went commercial or added a maintenance fee, before they surprise you.

Several popular .NET libraries have changed their terms: MediatR and AutoMapper went commercial, MassTransit v9 and FluentAssertions v8 need paid licences for commercial use, and Polly adds a maintenance fee for its next major version. Licence scanners that only read a package's licence label can miss these changes. Polly's licence, for example, stays BSD-3-Clause. They also don't tell you which version changed, whether the change applies to you, or what to do about it.

package-terms scans your solution and tells you, for each affected package:

Whether you're affected: the exact version you resolve, and whether you reference it directly or it comes in through another package or project
What changed and when, with a link to the official announcement
What to do: the last free version…

View on GitHub

If it saves you a surprise invoice, a ⭐ on GitHub helps other .NET developers find it. If it misses a package or gets something wrong, an issue with a link to the official source is even better.

4 HybridCache Gotchas I Only Found When I Tested My Own Sample

Paul Arun Prasath — Mon, 05 Oct 2026 07:15:40 +0000

My "under 5 ms" demo was running without an L2, hung on Redis and served stale data. I didn't notice any of it until I wrote tests.

Recently I published Serve API Responses in Under 5ms: HybridCache in .NET. The demo worked, the numbers looked great, and I was pretty happy with it.

Then I decided the repo deserved real tests, a CI pipeline with Redis and proper benchmarks instead of a curl script. I expected that to take an evening and confirm what I already knew.

It didn't. I found four problems. One was a plain bug in my code. The other three were HybridCache behaviours I simply hadn't understood. I never noticed any of them while clicking around by hand, and every one of them would have bitten me in production.

All the fixes are in the companion repo, and each one has a test that fails against the old code.

AddDistributedMemoryCache() doesn't give you an L2 My Program.cs looked like most HybridCache samples you'll find online:

builder.Services.AddDistributedMemoryCache(); // my "L2"
builder.Services.AddHybridCache();

My README even said AddDistributedMemoryCache() was "used as the L2 store". The logic seemed fine to me. HybridCache uses whatever IDistributedCache you register, so this should give me two levels of cache without running Redis on my laptop.

So I wrote a test for it. Two HybridCache instances play two pods. Each has its own L1, and they share one L2:

var sharedL2 = new MemoryDistributedCache(Options.Create(new MemoryDistributedCacheOptions()));
var podA = CreateHybridCache(sharedL2);
var podB = CreateHybridCache(sharedL2);

await podA.GetOrCreateAsync(key, Factory); // miss: factory runs, fills L1(A) and L2
await podA.GetOrCreateAsync(key, Factory); // L1(A) hit
await podB.GetOrCreateAsync(key, Factory); // L1(B) is empty, so this should come from L2

Assert.Equal(1, factoryCalls); // Actual: 2

The factory ran twice. Pod B found nothing in L2, because nothing had ever been written there.

I didn't quite believe it, so I went and read the source. It's right there in DefaultHybridCache's constructor:


// ignore L2 if it is really just the same L1, wrapped
if (_backendCache is not null
    && _backendCache.GetType() == typeof(MemoryDistributedCache)
    && _localCache.GetType() == typeof(MemoryCache))
{
    _backendCache = null;
}

When you think about it, it's a reasonable optimisation. MemoryDistributedCache lives in the same process, so using it as L2 would just mean serializing a second copy of L1. HybridCache notices and switches L2 off.

The awkward part for me: my sample had been running with L1 only the whole time. The L1 → L2 → factory flow I walked through in the article never actually happened unless you ran Redis.

If you want a real L2, use an out-of-process store like Redis, SQL Server or Postgres. If you only want an in-process L2 for tests, wrap MemoryDistributedCache in a small pass-through class. The check compares exact types, so the wrapper counts as a real L2:


public class PassThroughDistributedCache(IDistributedCache inner) : IDistributedCache
{
    public byte[]? Get(string key) => inner.Get(key);
    public Task<byte[]?> GetAsync(string key, CancellationToken token = default) => inner.GetAsync(key, token);
    // Set, SetAsync, Refresh, RefreshAsync, Remove and RemoveAsync delegate the same way
}

The official HybridCache docs didn't mention this, so I sent a pull request to add a note. Microsoft merged it, and it's now live on Microsoft Learn.

Hopefully it saves someone else the head-scratching.

Redis and HybridCache deadlocked on the first request Fine, I thought. I'll wire up Redis properly.

var redis = builder.Configuration.GetConnectionString("Redis");
if (!string.IsNullOrWhiteSpace(redis))
{
    builder.Services.AddStackExchangeRedisCache(o => o.Configuration = redis);
}
builder.Services.AddHybridCache();

My Redis tests went green. Then I started the actual API against Redis, sent GET /products, and... nothing. The app had started normally. The connection was accepted. The request just sat there, with no exception, no log line and no timeout.

The tests had passed for a boring reason. They created the cache with new RedisCache(...), while the API used AddStackExchangeRedisCache(...). That one difference was the whole problem.

I took a stack dump with dotnet-stack, and the loop was easy to spot:


RedisCacheImpl..ctor(IOptions<RedisCacheOptions>, IServiceProvider)
  RedisCacheImpl.IsHybridCacheDefined(IServiceProvider)
    DefaultHybridCache..ctor(IOptions<HybridCacheOptions>, IServiceProvider)
      RedisCacheImpl..ctor(...)
        RedisCacheImpl.IsHybridCacheDefined(...)
          DefaultHybridCache..ctor(...)
            ...

Building HybridCache resolves the IDistributedCache. In Microsoft.Extensions.Caching.StackExchangeRedis 9.0.3, the Redis cache's constructor checks whether HybridCache is registered by... resolving HybridCache. Two singletons, each waiting for the other to finish being created. Forever.

It's a known bug, already reported and fixed upstream in dotnet/aspnetcore#60894. Upgrading the Redis package sorted it out. I confirmed that 9.0.20 works; the issue will tell you the first patched version.

What I took away from this one:

If you use HybridCache with AddStackExchangeRedisCache, check which Redis package version you're on.
Test the app the way it actually runs. My tests built RedisCache by hand and never went near the DI path that deadlocked. The regression test I added runs the whole API through WebApplicationFactory with Redis configured, and fails if GET /products takes longer than 10 seconds.
When something hangs and logs nothing, take a stack dump before you start guessing. One command took me from "is Redis broken?" to the exact constructor cycle.

The L2 write can land after GetOrCreateAsync returns With Redis fixed, I pointed my two-pod test from gotcha 1 at real Redis. It still failed. Pod B called its factory again.

When I checked Redis afterwards, the keys were there. They just weren't there yet when pod B asked. In my tests, HybridCache handed the value back before its Redis write had finished. My in-memory wrapper wrote synchronously, so it had hidden this completely.

For the test, the fix was to wait for the entry to show up in L2 before asking the second instance:

// HybridCache can return the value before its L2 write completes,
// so wait for the entry to land in L2 before asking the second instance.
var deadline = DateTime.UtcNow.AddSeconds(5);
while (await sharedL2.GetAsync(key) is null && DateTime.UtcNow < deadline)
    await Task.Delay(10);

The bigger lesson is about production. If two instances ask for the same key at almost the same moment, both can miss L2 and both can run the factory. Stampede protection works inside one process. It doesn't cover your whole fleet.

So make your factories safe to run more than once, and cheap enough that it doesn't matter much when they do. If something really must run only once across all your instances, you need a distributed lock or a different design, because HybridCache won't do that for you. And in tests, don't assume an L2 write is visible straight away.

Tag invalidation only clears what you actually tagged This one's entirely my fault, but I suspect it's a common mistake.

My original service tagged the list with products, and each item with products plus product:{id}:


// list
cache.GetOrCreateAsync("products:all", ..., tags: ["products"]);
// item
cache.GetOrCreateAsync($"product:{id}", ..., tags: ["products", $"product:{id}"]);

// update
await cache.RemoveByTagAsync($"product:{id}"); // "invalidates both the item and any list"

Look at that comment. It's wrong. The list never had the product:{id} tag, so updating product 1 cleared the cached item while GET /products kept showing the old name for up to five minutes. My curl script never caught it, because after an update it only checked the item, never the list.

The fix was to give each kind of entry its own tag, and clear every affected tag on every write:

public const string ListTag = "products:list";
public static string ItemTag(int id) => $"product:{id}";

// update and delete: the item and the list both contain the old values
await cache.RemoveByTagAsync([ListTag, ItemTag(id)], ct);

// create: the list is stale, and an earlier GET for this id may have cached "not found"
await cache.RemoveByTagAsync([ListTag, ItemTag(created.Id)], ct);

That last line also handles a sneaky case. GetOrCreateAsync will happily cache null, so calling GET /products/5 before product 5 exists caches "not found" until it expires.

The habit I've picked up: for every write, list every cached view that shows the changed data, and check that each one carries a tag you clear. Then write the test from the reader's side. Update something, then read every endpoint that displays it.

One more thing you'll notice with Redis as L2 is keys like MSFT_HCTproducts:list sitting next to your data. That's HybridCache keeping track of tag invalidations, so don't let a clean-up script delete them.

So, is it still under 5 ms?
Yes, and this time I have numbers instead of a curl script. BenchmarkDotNet on .NET 9, with Redis 7 running in Docker:


Served by                                   Mean
L1 hit (in-process)                       0.88 µs
L2 hit (Redis + deserialize)               288 µs
Miss (factory, 30 ms simulated database)  31.1 ms

Over real HTTP on localhost, a cached GET /products took about 1.5 ms, compared with about 127 ms for the first, uncached call. In production you'll add your network round-trip on top. The benchmarks are in the repo if you want to run them on your own hardware.

What I'd tell myself before writing the first article
Check that each cache layer works, not just that the endpoint is fast. A fast response proves something was cached. It doesn't tell you which cache, or whether the other one is even switched on.
Test the app the way it really runs. My component tests were green while the real setup deadlocked.
Treat stampede protection as per-process. Across instances, assume the factory can run more than once.
Test invalidation from the reader's side.
The full sample is on GitHub, with the tests, the benchmarks and a CI pipeline that runs everything against Redis: paulap887/HybridCache.

Have you run into HybridCache surprises of your own? Tell me in the comments. I'd really like to know what I've missed.

Originally published on Level Up Coding.