Setting SlidingExpiration on a CacheEntry has some seemingly undocumented behavior

[VelvetToroyashi]

Description

👋🏽 Wanted to preface this by saying: First time opening an issue here, please correct me if I misspeak.

This issue stems from the implementation of the Microsoft.Extensions.Caching.Memory package, and from the looks of it, specifically on CacheEntry. While looking into this issue, I wanted to make sure someone else hadn't already reported it, but the closest I could find regarding this exact issue is a question (posted here).

When setting an absolute expiration, it makes sense that when that expiration passes, the object is removed, and this behavior also extends to sliding expirations, of which presumably get reset when the value is retrieved. This is fine, expected, and documented behavior. The documentation seems to be lacking in the nuance of sliding expirations, though.

If a sliding expiration is set, and an absolute expiration is absent, the sliding expiration then acts as an "absolute" expiration (from the time the object is inserted, it seems?). This is slightly confusing, at least to myself, since if the object is never "accessed", the sliding expiration cannot kick in.

Reproduction Steps

using System;
using System.Threading.Tasks;
using Microsoft.Extensions.Caching.Memory;
using Microsoft.Extensions.DependencyInjection;

namespace MinimalRepro;

public static class Program 
{
    public static async Task Main()
    {
        var services = new ServiceCollection();
        services.AddMemoryCache();

        var provider = services.BuildServiceProvider();
        var cache = provider.GetRequireService<IMemoryCache>();

        var cacheOptions = new new MemoryCacheEntryOptions()
        cacheOptions.SetSlidingExpiration(TimeSpan.FromSeconds(5));
        
        cache.Set("example_key", "example_value", cacheOptions);

        await Task.Delay(TimeSpan.FromSeconds(5));

        var keyExists = cache.TryGetValue("example_key", out _);

        if (!keyExists)
            Console.WriteLine("The cached value has gone missing!");
    }
}

Expected behavior

The expiration timer is started when the value is initially accessed.

Actual behavior

The object will expire from cache regardless of whether it's been "accessed"; this is likely due to the LastAccessed property of a CacheEntry being a non-nullable DateTime, which appears to default to 1/1/0001 12:00:00 AM.

Regression?

I'm unsure, but I'm doubtful of it.

Known Workarounds

No response

Configuration

.NET 6.0.100

Windows 10, 21H1, 64-bit.

This issue should be platform-agnostic.

Other information

The issue is within this code, and I believe is due to the issue regarding the datetime being initialized with a default value that will almost always be greater than the expiration, or so I'd hope 😄.

While I wouldn't say that this is a bug or incorrect behavior, I think at the very least the documentation (MSDN Link) should be updated to reflect this otherwise undocumented behavior.

Tagging subscribers to this area: @dotnet/area-extensions-caching
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

👋🏽 Wanted to preface this by saying: First time opening an issue here, please correct me if I misspeak.

This issue stems from the implementation of the Microsoft.Extensions.Caching.Memory package, and from the looks of it, specifically on CacheEntry. While looking into this issue, I wanted to make sure someone else hadn't already reported it, but the closest I could find regarding this exact issue is a question (posted here).

When setting an absolute expiration, it makes sense that when that expiration passes, the object is removed, and this behavior also extends to sliding expirations, of which presumably get reset when the value is retrieved. This is fine, expected, and documented behavior. The documentation seems to be lacking in the nuance of sliding expirations, though.

If a sliding expiration is set, and an absolute expiration is absent, the sliding expiration then acts as an "absolute" expiration (from the time the object is inserted, it seems?). This is slightly confusing, at least to myself, since if the object is never "accessed", the sliding expiration cannot kick in.

Reproduction Steps

using System;
using System.Threading.Tasks;
using Microsoft.Extensions.Caching.Memory;
using Microsoft.Extensions.DependencyInjection;

namespace MinimalRerpo;

public static class Program 
{
    public static async Task Main()
    {
        var services = new ServiceCollection();
        services.AddMemoryCache();

        var provider = services.BuildServiceProvider();
        var cache = provider.GetRequireService<IMemoryCache>();

        var cacheOptions = new new MemoryCacheEntryOptions()
        cacheOptions.SetSlidingExpiration(TimeSpan.FromSeconds(5));
        
        cache.Set("example_key", "example_value", cacheOptions);

        await Task.Delay(TimeSpan.FromSeconds(5));

        var keyExists = cache.TryGetValue("example_key", out _);

        if (!keyExists)
            Console.WriteLine("The cached value has gone missing!");
    }
}

Expected behavior

The expiration timer is started when the value is initially accessed.

Actual behavior

The object will expire from cache regardless of whether it's been "accessed"; this is likely due to the LastAccessed property of a CacheEntry being a non-nullable DateTime, which appears to default to 1/1/0001 12:00:00 AM.

Regression?

I'm unsure, but I'm doubtful of it.

Known Workarounds

No response

Configuration

.NET 6.0.100

Windows 10, 21H1, 64-bit.

This issue should be platform-agnostic.

Other information

The issue is within this code, and I believe is due to the issue regarding the datetime being initialized with a default value that will almost always be greater than the expiration, or so I'd hope 😄.

While I wouldn't say that this is a bug or incorrect behavior, I think at the very least the documentation (MSDN Link should be updated to reflect this otherwise undocumented behavior.

Author:	VelvetThePanda
Assignees:	-
Labels:	untriaged, area-Extensions-Caching
Milestone:	-

[Tornhoof]

Can you explain why you think the current behavior is not what you'd expect?
The current behavior makes sense from an usage perspective, if you don't use the cache it will get evicted. It would be strange, from my pov, if it would only get evicted if you'd used it atleast once.

I'm not sure why you think this is undocumented behaviour, the link you have states:
Gets or sets how long a cache entry can be inactive (e.g. not accessed) before it will be removed.

For the old MemoryCache in Runtime it's documented slightly differently in https://docs.microsoft.com/en-us/dotnet/api/system.runtime.caching.cacheitempolicy.slidingexpiration?view=dotnet-plat-ext-6.0
A span of time within which a cache entry must be accessed before the cache entry is evicted from the cache.
This is stated in a way that it needs to be accessed for the sliding to be refreshed.

In https://docs.microsoft.com/en-us/aspnet/core/performance/caching/memory?view=aspnetcore-6.0#use-imemorycache this behavior is documented too:
In the preceding code, the cache entry is configured with a sliding expiration of three seconds. If the cache entry isn't accessed for more than three seconds, it gets evicted from the cache.