You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There seems to be a bug in the logic as IsExpired compared absolute expiration against the created date. But when extending the absolute expiration, the timespan gets calculated with the current UtcNow.
When doing that a few times, IsExpired will start to return true although the item is not expired.
Workaround for now is to create a new CacheItem everytime you manally extend absolut expiration (if you need to manually control/build your own sliding expiration).
Solution would be to actually rewrite/modify the created date the moment absolute expiration gets modified. Or, safe another date field instead which might be even more data to store in Redis etc...
The text was updated successfully, but these errors were encountered:
There seems to be a bug in the logic as IsExpired compared absolute expiration against the created date. But when extending the absolute expiration, the timespan gets calculated with the current UtcNow.
When doing that a few times, IsExpired will start to return true although the item is not expired.
Workaround for now is to create a new CacheItem everytime you manally extend absolut expiration (if you need to manually control/build your own sliding expiration).
Solution would be to actually rewrite/modify the created date the moment absolute expiration gets modified. Or, safe another date field instead which might be even more data to store in Redis etc...
The text was updated successfully, but these errors were encountered: