Community member @suhrab kindly reported that when using TimeSpan.MaxValue as the Duration, an ArgumentOutOfRangeException is being thrown when instead it should have been handled.
This, in turn, made a pattern emerge with which for "never expiring cache entries" the common way to do it may be to just set the duration to TimeSpan.MaxValue.
This situation, although maybe not that frequent, should be better handled.
Solution
Setting the Duration to TimeSpan.MaxValue is a scenario that should be gracefully handled.
Also, other similar edge case scenarios should be handled, like:
setting the Duration to a value lower than TimeSpan.MaxValue but still such that, when added to the current UtcNow, will result in an ArgumentOutOfRangeException
all of the above, plus jittering: so that even if Duration + UtcNow is still below the max expiration, the thing would not throw when adding some jittering (if enabled)
On top of this it would be nice to add to FusionCacheEntryOptions a couple of methods like SetDurationInfinite() and SetDistributedCacheDurationInfinite().
This would:
help users in such scenarios, by having an official and uniform way to approach this need instead of, say, doing something like setting the Duration to 100 years or something like that;
allow some internal optimizations, since instead of having for example a Duration of 100 years which would still need to be added to UtcNow to calculate the actual expiration, FusionCache would recognize the user's intent for the Duration to be "logically infinite" and just set the expiration to the max possible value
Additional context
Nitpicking corner: the "infinite duration" would be for all intent and purposes, practically infinite. Having said that it cannot be of course literally infinite, but instead will be DateTimeOffset.MaxValue which in turn is Dec 31st 9999.
In the xml docs I'm putting something like this:
/// <summary>
/// Set the duration to be infinite, so it will never expire.
/// <strong>NOTE:</strong> the expiration will not be literally "infinite", but it will be set to <see cref="DateTimeOffset.MaxValue"/> which in turn is Dec 31st 9999 which, I mean, c'mon. If that time will come and you'll have some problems feel free to try and contact me :-)
/// </summary>
Problem
Community member @suhrab kindly reported that when using
TimeSpan.MaxValue
as theDuration
, anArgumentOutOfRangeException
is being thrown when instead it should have been handled.This, in turn, made a pattern emerge with which for "never expiring cache entries" the common way to do it may be to just set the duration to TimeSpan.MaxValue.
This situation, although maybe not that frequent, should be better handled.
Solution
Setting the
Duration
toTimeSpan.MaxValue
is a scenario that should be gracefully handled. Also, other similar edge case scenarios should be handled, like:Duration
to a value lower thanTimeSpan.MaxValue
but still such that, when added to the currentUtcNow
, will result in anArgumentOutOfRangeException
Duration
+UtcNow
is still below the max expiration, the thing would not throw when adding some jittering (if enabled)On top of this it would be nice to add to
FusionCacheEntryOptions
a couple of methods likeSetDurationInfinite()
andSetDistributedCacheDurationInfinite()
. This would:Duration
to100 years
or something like that;Duration
of100 years
which would still need to be added toUtcNow
to calculate the actual expiration, FusionCache would recognize the user's intent for theDuration
to be "logically infinite" and just set the expiration to the max possible valueAdditional context
Nitpicking corner: the "infinite duration" would be for all intent and purposes, practically infinite. Having said that it cannot be of course literally infinite, but instead will be
DateTimeOffset.MaxValue
which in turn is Dec 31st 9999. In the xml docs I'm putting something like this:I know, but still better to specify that 😅.