Update dependency ZiggyCreatures.FusionCache to 1.4.1

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
ZiggyCreatures.FusionCache	1.2.0 -> 1.4.1

---

Release Notes

ZiggyCreatures/FusionCache (ZiggyCreatures.FusionCache)

v1.4.1

This is a small version, just to update some transitive packages with security vulnerabilities.

⚠️ Update vulnerable dependencies

The affected transitive packages are:

• System.Text.Json
• MessagePack
• Microsoft.Extensions.Caching.Memory

To that to update Microsoft.Extensions.Caching.Memory, an update for System.Diagnostics.DiagnosticSource was also needed.

This is all.

PS: if you have some time, please read the Tagging proposal (eg: evict by tag + clear), which is planned for v2.0. This will be one of the biggest and most important features of FusionCache ever. Any help is welcome!

v1.4.0

[!IMPORTANT]
Although when updating to a new version it's the norm to update all referenced packages at once, this time is even more important. Because of a small change in the IFusionCacheSerializer interface, it is highly suggested to update all packages, including in transitive dependencies.

🚀 Add support for RecyclableMemoryStream to serializers (docs)

It is now possible to use RecyclableMemoryStreams with some of the supported serializers.
It's opt-in, meaning totally optional, and it's possible to use the default configuration or to specify one in the constructor, for maximum control and to fine-tune it however we want.

Thanks @​viniciusvarzea for the suggestion!

See here for the original issue.

🔭 Better observability for GET operations (docs)

Community user @​dotTrench noticed that when using OpenTelemetry, GET activities (TryGet, GetOrDefault, etc) were not including a useful bit of information: the hit/miss status.
While adding support for it via an extra tag, it was also noticed that it was not including another useful bit of information: the stale/fresh status.
Now this is solved, thanks to 2 new tags.

See here for the original issue.

💣 Throw specific exception when factory fails without fail-safe (docs)

Since v1.3.0 it's possible to trigger a factory fail without throwing an exception, so that fail-safe can kick in and do its thing.

But what happens if fail-safe is not enabled or if there's no stale value to fall back to?

Previously a plain Exception was being thrown, but that is hardly a best practice: now a more specific exception type has been created and will be thrown instead, namely FusionCacheFactoryException.

See here for the original issue.

🛑 Add cancellation support to serializers (docs)

Previously serializers did not support cancellation: now this is supported, via the standard CancellationTokens.

Thanks @​b-c-lucas for noticing it!

See here for the original issue.

🚀 Better perf for FusionCacheProvider (docs)

Community user @​MarkCiliaVincenti contributed with a PR that improved the performance of FusionCacheProvider, used with Named Caches, thanks to the use of FrozenDictionary.

See here for the original PR.

🐞 Respect the Size of an entry loaded in L1 from L2 (docs)

Community user @​Amberg noticed that when the MemoryCache (L1) passed to FusionCache had a SizeLimit configured, and an entry wasbeing saved with a Size specified, that was not used when automatically getting the same entry from another node via the distributed cache, causing an issue.

Now this is solved, in 2 different scenarios:

• common case: setting an entry WITH a specific size on a cache WITH size limit, and then getting the same entry from another cache (WITH size limit, too), meaning it restores the entry with its size
• edge case (and probably a wrong setup anyway): setting an entry WITHOUT a specific size on a cache WITHOUT a size limit, and then getting the same entry from another cache (but WITH size limit) works if there's at least a Size specified in the entry options (either for the specific method call or in the DefaultEntryOptions). This is more of an edge case, since usually what is logically the same cache should be configured the same for every instance (a.k.a. on every node)

See here for the original issue.

✅ Way better tests

As always some tests have been added for each new feature.
On top of that though, the testes have been changed to make them even more resilient to microscopic differences between different runtimes, OSs, etc: most of the problems were related to this almost unknown behaviour.
This helped make the entire test suite even more stable and with a predictable outcome, both locally and on GitHub actions.

Overall, FusionCache currently has around 750 tests, including combinatorial params.

See here for some juicy details.

📕 Docs

Updated some docs with the latest new things.

v1.3.0

♊ Auto-Clone (docs)

In general is never a good idea to mutate data retrieved from the cache: it should always be considered immutable/readonly.
To see why, read more in the docs.

Not all the scenarios where mutating a piece of data we got from the cache are necessarily wrong though, as users may have a particular use case where that may be needed, and ideally they should be abe to do that in an easy (and optimized!) way, by following the tried and true "it just works" mindset.

With Auto-Clone this is now possible.

A couple of details:

• it just works, out of the box
• is easy to use
• doesn't require extra coding/setup (it's just a new EnableAutoClone option)
• uses existing code infrastructure (eg: IFusionCacheSerializer)
• has granular control on a per-entry basis
• is performant (as much as possible)

Thanks to community users @​JarrodOsborne and @​kzkzg !

See here for the original issue.

💣 Fail-Safe Without Exceptions (docs)

Currently the way to activate fail-safe is for a factory to throw an exception.

This makes sense, since the whole point of fail-safe is to protect us when an error occurs while executing a factory.

But there may be other ways to do it, for example by using a variation of the Result Pattern or similar approaches, in which throwing an exception is not necessary.

This is now possible thanks to the new Fail(...) method on the FusionCacheFactoryExecutionContext<TValue> type, which we can access when executing a factory.

A quick example:

var productResult = await cache.GetOrSetAsync<Result<Product>>(
	$"product:{id}",
	async (ctx, ct) =>
	{
		var productResult = GetProductFromDb(id);

		if (productResult.IsSuccess == false)
		{
			return ctx.Fail(productResult.Error);
		}

		return productResult;
	},
	opt => opt.SetDuration(duration).SetFailSafe(true)
);

Thanks to community user @​chrisbbe that noticed it!

See here for the original issue.

🧙‍♂️ Adaptive Caching on errors (docs)

Previously it was not possible to use adaptive caching when an error occurred during a factory execution.
This was usually not a big issue, but it left a particular edge case not fully uported: selectively enabling/disabling fail-safe on errors.
Now this is possible, in the usual unified way.

Thanks to community user @​cmeyertons for spotting it, and for creating the PR that solved it.

See here for the original issue.

📦 More granular (and less) dependencies with multi-targeting

Thanks to a note by community user @​thompson-tomo FusionCache now multi-targets different .NET vesions.
This was not needed per-se, but by doing it FusionCache can now have less dependencies for some TFMs.

See here for the original issue.

🚀 Better perf for FusionCacheProvider (docs)

Community user @​0xced contributed with a PR that improved the performance of FusionCacheProvider, used with Named Caches.

See here for the original PR.

⚠️ Update dependencies for CVE-2024-30105

Communicty user @​dependabot (😅) noticed CVE-2024-30105 and promptly bumped the referenced version of the System.Text.Json package.

Note that this is only related to the package ZiggyCreatures.FusionCache.Serialization.SystemTextJson.

✅ Better tests

Some tests have been added for each new feature, and overall better snapshot tests.

📕 Docs

Updated some docs with the latest new things.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.