Interface IUserCacheInvalidator
Implemented by a user store that caches resolved users, so something outside it can drop a stale entry. UserServiceBase implements it; a store written from scratch need not.
public interface IUserCacheInvalidatorRemarks
This exists because the cache belongs to the toolkit and the writes do not. UserServiceBase
invalidates in the paths it owns, and a host overriding one of those to supply persistence
replaces the path that invalidates — so the write commits and every later read is served
stale. The host has no reason to know the cache exists, and nothing told it.
The symptom is worth recognising: a change appears not to take, survives every page reload, and corrects only on process restart. Nothing else looks like that. A write that never landed looks identical on screen and has the opposite fix, which is what made it cost two diagnoses.
Keyed by Key rather than identity because that is what the mutating members take. The cache is small — one entry per signed-in user per process — so the scan is cheaper than maintaining a second index.
Methods
InvalidateUserByKey(string)
Drops any cached copy of the user with this key. A no-op when nothing is cached for it, so it is always safe to call and safe to call twice.
void InvalidateUserByKey(string userKey)Parameters
userKeystring
InvalidateUserByKeyAsync(string)
The asynchronous form, which is what the toolkit calls. Prefer implementing this one: the cache may be a remote store (see ITeamCache), and the synchronous member can then only be served by blocking.
Task InvalidateUserByKeyAsync(string userKey)Parameters
userKeystring
Returns
Remarks
Defaulted to the synchronous member so an existing implementation keeps compiling and keeps working.