CachePolicy does not cache results of type default(TResult)

[reisenberger]

CachePolicy does not cache results of type default(TResult)

value-type case

x-ref:

• https://github.com/App-vNext/Polly/wiki/Cache#caching-defaulttresult-for-value-types
• boolean 'false' values are never cached (generalised: default(TResult) for value types) Polly.Caching.MemoryCache#28

reference-type case

ie ability to cache null

x-ref:

• boolean 'false' values are never cached (generalised: default(TResult) for value types) Polly.Caching.MemoryCache#28 (comment)

[reisenberger]

@cmeeren We are now working towards a major release (v7.0) of Polly, so we have the opportunity to take the breaking change to fix this. Are you interested in pitching in a PR to fix this?

It relates to the issue you raised in more detail here.

---

Needed would be:

(1) Adapt the ISyncCacheProvider and IAsyncCacheProvider interfaces, so that the get methods were of the form (say):

(bool, object) TryGetValue(String key);

and

Task<(bool, object)> TryGetValueAsync(String key, CancellationToken cancellationToken, bool continueOnCapturedContext);

• where the bool return value represents cache hit or miss. (The .Net Standard 1.1 target would need to take a dependency on the nuget package System.ValueTuple.)
• Other suggestions welcome: the goal is to remove default(TResult) representing cache miss.
• An alternative to pulling in System.ValueTuple could be to define a mini struct representing the value and whether or not we got one, similar to Service Fabric's ConditionalValue<TResult>

(2) Adapt the sync cache policy engine and async cache policy engine for the fact that we would have some bool indicating cache hit/miss, rather than default(TResult)

(3) Add suitable/adapt existing tests

---

Then we would want to bring Polly's two cache provider implementations into line with these simple changes:

(a) Polly.Caching.MemoryCache
(b) Polly.Caching.IDistributedCache

---

We could also split more than one person over the work, if people were interested.

[reisenberger]

Marking this 'up-for-grabs', for anyone interested

[cmeeren]

I'm currently swamped with other work, so for the sake of me and mine I have to pass on this. Hoping someone else will be able to do this! 🤞

[reisenberger]

Thanks @cmeeren for the fast response. I also have to choose goals, so leaving this up-for-grabs ...

[cmeeren]

I'll try to take a stab at this today.

[cmeeren]

I think the common pattern is to use out params: bool TryGet(String key, out object result);

This also avoids an extra struct as well as the dependency on System.ValueTuple. Will try this.

Edit: Oh wait, you can't do that with async. I'll go for tuples instead, I think.

[reisenberger]

@cmeeren Awesome. And: thank you!

I'm hoping to get v7 out early next week (the code is otherwise done; only finishing doco), so that would be perfect timing. Thanks for contributing!

[reisenberger]

Fixes merged to the v7.0.0 branch