2nd call to MemoryCache.Set() with the same key erases entry if cache is full

[anderslyman]

Describe the bug

If I make a call to MemoryCache.Set() to update an existing item when the cache is full (size limit reached), the item is instead removed.

To Reproduce

Steps to reproduce the behavior:
LINQPad script: http://share.linqpad.net/kmpxj3.linq

void Main()
{
    var memoryCache = new MemoryCache(new MemoryCacheOptions
    {
        SizeLimit = 1 // <-- Setting to 2 fixes the issue
    });

    Set(memoryCache);
    memoryCache.Get("A").Dump(); // Yields 1
    Set(memoryCache);
    memoryCache.Get("A").Dump(); // Yields null
}

private void Set(MemoryCache memoryCache)
{
    //memoryCache.Remove("A"); // <-- Also fixes the issue

    memoryCache.Set("A", 1, new MemoryCacheEntryOptions
    {
        AbsoluteExpirationRelativeToNow = TimeSpan.FromDays(1), 
        SlidingExpiration = TimeSpan.FromDays(1), 
        Size = 1
    });
}

Expected behavior

I would expect the item to be updated.

Additional Info

Initially posted a question here:
https://stackoverflow.com/questions/60626316/2nd-call-to-memorycache-set-with-the-same-key-erases-entry-if-cache-is-full

There was a link added by another user to a related, closed bug: dotnet/extensions#1889
While this is a different scenario, it seems like it might have the same root cause.

[ericstj]

Agreed it appears to be same root case. Set actually ends up calling CreateEntry. If you wanted to update an entry you could try calling TryGetValue although here that wouldn't help since your value is not mutable (int). I suspect that there is something that could be tweaked here to improve the case where two entries are created with the same key name. We can take a look.

[anderslyman]

In our case it was simple to adjust the capacity of the cache with desiredSize + 1 since we know ahead of time how many entries we want to store.
It'd be good to fix it, but I think leaving this as a known bug along with a note in the docs would be pretty acceptable too.

[danmoseley]

There is a test for this, which suggests it was intentional behavior:

runtime/src/libraries/Microsoft.Extensions.Caching.Memory/tests/CapacityTests.cs

Line 274 in 3921b8e

public void AddingReplacementExceedsCapacityRemovesOldEntry()

@Tratcher