AbsoluteExpiry of caller overridden/ignored if child called that causes cache entry with shorter expiry

[LittleColin]

If method A caches for 12 hours and calls method B which caches for 5 minutes, the result for method A will only be cached for 5 minutes.

Logically this appears to make sense but this happens without the caller for Method A knowing about it. Consider the situation where method A goes on to make calls to a system that has a quota that mustn't be called too frequently. There should at least be an error if Method A has set an absolute expiry that is subsequently ignored/overridden by the call to Method B.

It relates to this change: https://github.com/aspnet/Caching/commit/f15fb804cdc2e14f9a64896817f3c6c343110820#diff-9968fc5543acfd05fa60089bd344679bR102

The actual behaviour appears to contradict the bullet point above but that could depend on your interpretation of which is child and which is parent in the scenario I've described: "When one cache entry is used to create another, the child copies the parent entry's expiration tokens and time-based expiration settings. The child isn't expired by manual removal or updating of the parent entry."

I've put a code example here: https://sartorialsolutions.wordpress.com/2019/02/15/aspnetcore-memorycache-magic-dependencies-and-danger/

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 13f5f8f9-18dd-9c12-9ed1-fcc6b44ba7fd
• Version Independent ID: 640b4f36-5886-7b69-1c95-cfc8574a02fd
• Content: Cache in-memory in ASP.NET Core
• Content Source: aspnetcore/performance/caching/memory.md
• Product: aspnet-core
• GitHub Login: @Rick-Anderson
• Microsoft Alias: riande

[Rick-Anderson]

there should at least be an error if Method A has set an absolute expiry

You can open a issue for that at https://github.com/aspnet/AspNetCore/issues

The actual behaviour appears to contradict the bullet point above

What bullet point in the doc? What would you like see changed in the doc?

[LittleColin]

Thanks for the response @Rick-Anderson. The bullet point was the part I quoted (it was "above" when I created this issue on https://docs.microsoft.com/...):

"When one cache entry is used to create another, the child copies the parent entry’s expiration tokens and time-based expiration settings. The child isn’t expired by manual removal or updating of the parent entry."

But perhaps this is talking about an entirely different scenario of creating child cache items.

[mkArtakMSFT]

@ericstj another caching related issue.

[ericstj]

cc @maryamariyan @eerhardt

[ericstj]

Also cc @sebastienros who made the change referenced here.

[Rick-Anderson]

@mkArtakMSFT https://github.com/dotnet/aspnetcore-internal/wiki/Team-Ownership doesn't say who own's caching so adding label re-Artak, feel free to use another label

[mkArtakMSFT]

Fixed and rerouted to @adityamandaleeka