Avoid Caching with MemoryCache and GetOrCreate in .NET

GetOrCreate or its asynchronous counterpart GetOrCreateAsync is an extension method to create a cache entry if it does not exist yet.

This method takes a key and a function that is used to create the object, and it returns the object that is stored in the cache for the specified key. If the object does not exist in the cache, the function will be called to create the object, which will then be added to the cache and returned by the GetOrCreate method.

The problem: in principle every result of the delegate is added to the cache, which is sometimes, with certain values then nevertheless not desired.

If we do not want to cache null values in a scenario: at first glance, it does not seem to work without a workaround. You see various workarounds on the net to simply set the ExpiredOn time point in the past, but is that really so great?

entry.AbsoluteExpirationRelativeToNow = TimeSpan.Zero;

But a look into the source code reveals that Dispose() is the solution:

Each cache entry is surrounded by ICacheEntry, which implements Disposable and is used in the implementation of MemoryCache to remove an entry. So, lets dispose the entry!

string cacheKey = "My.Cache.Key." + userId;

// get entry from cache or request and store in cache
CustomerDataModel? customerData = await _cache.GetOrCreateAsync(cacheKey, async (cacheEntry) =>
{
    // get data
    ApiResponse<CustomerDataModel> anyResponse = await _myHttpClient.GetFromApiEndpoint(userId).ConfigureAwait(false);

    CustomerDataModel? data = anyResponse.Data;

    // if data is null, dont cache
    if (data is null)
    {
        cacheEntry.Dispose();
        return null;
    }

    // if data is not null, cache for ever
    //    you can also set the expiration here
    return data;

    // This works!
}).ConfigureAwait(false);

Pitfalls

Setting a value must not be done before the Dispose, otherwise the entry will end up in the cache after all!

cacheEntry.Value = data; // <<-- dont do that
cacheEntry.Dispose();

Conclusion

Dispose seems to be the perfect way here, even though I couldn't find any documentation on the behavior. In principle, however, it is a documented API and since the Dispose behavior is not internal, one can expect that this behavior will not change for the time being, but that the behavior will remain stable and can thus also be used in productive scenarios.

Thanks also to gfoidl, who gave me the decisive tip.