Clear user timezone cache when user is updated

[deanmarcussen]

Related to the improvements to the user timezone cache in the UserTimeZoneService

OrchardCore/src/OrchardCore.Modules/OrchardCore.Users/TimeZone/Services/UserTimeZoneService.cs

Line 18 in a2d529e

private static readonly DistributedCacheEntryOptions _slidingExpiration = new() { SlidingExpiration = TimeSpan.FromHours(1) };

Because it's gone to sliding, if the user changes their timezone (we allow the user to manage it themselves as part of their user profile), I would suggest a user event handler, which would clear the cache when the user is updated, would be useful.

The current scenario, because it's a sliding expiration, means the user will never see a timezone change when they make their settings, until they stop for the day, and have no activity for +1 hour.

An absolute expiration might be a sensible backup option as well, in case the handler doesn't fire.

I will probably write one when we do our next upgrade to OC, so would commit it back, but that upgrade maybe a few more months away for us :)

[KeithRaven]

@deanmarcussen can I pick this one up? :)

[sebastienros]

@KeithRaven you got a thumbs up from @deanmarcussen

[KeithRaven]

@deanmarcussen I've assumed that your updating user profiles through custom code as the UserTimeZoneDisplayDriver was already clearing the cache on update, so when using the built in UI it seemed fine.

I've added a handler to clear the cache on both update and delete of a user, as deleting and recreating a user (again not through the main UI) would also pick up the stale cached value. I've cleared the cache in the same way the driver did but removed that line from the driver as it now seemed superfluous.

I've not added an absolute expiration yet as I couldn't see under what circumstances the handler might not fire, perhaps you had something in mind?

[deanmarcussen]

@KeithRaven yes, custom code on our front end does the updates, so outside the driver scopes.

An abolute expiration was yes, just in case the handler doesn't fire. I have been finding that with redis and a couple of servers things can get stuck there a bit easier, so I'm tending to always expire eventually, so things self heal. Not a major issue, just annoying when turning the server on and off again doesn't fix it!

[KeithRaven]

@deanmarcussen So not so much the handler itself not firing but some distributed cache implementations maybe not 100% reliable when clearing?

I sat on it a few days as I was over thinking it wondering if it was the right place for a mitigation for particular cache providers, but I think making it configurable is probably overkill for such a small thing and so probably just a sensible default. Does 4hrs seem reasonable?