It should be possible to force the removal of entries / overwriting Fail-Safe

[charlesvigneault]

I would want to use Fail-Safe for my authorization but it's not possible without being able to force remove entries.

My case is:

1. I ping auth service to know if the user is authorized for a specific resource.
2. I use a cache named "Auth-UserID-Resources" and a tag "Auth-UserID"
3. I use Fail-Safe with SlowTimeout so the user don't wait for more than 50ms for authorization for every subsequent api call.
4. The admin change the permissions of the user.
5. I use RemoveByTag("Auth-UserID", force: true) to remove every auth cache.
6. The user lose access instantly

This should be possible using Tags, Clear and Remove.

[jodydonetti]

Hi @charlesvigneault , so if I got this right the issue is that you want fail-safe enabled for the entry for the soft timeout part, but not when doing a RemoveByTag(), correct?

Something you can try is to disable fail-safe and use Eager Refresh instead of soft timeout: in this way before the entry expires a non-blocking background refresh will be done (you'll be still protected from cache stampede, of course) and in that case the RemoveByTag() will wipe the entries for good.

Of course there's one thing to consider: if the data is not accessed after the eager refresh threshold is it and before the expiration, but only after the expiration, a slow api call would slow down the response.

Is this something that may work for you?

Meanwhile I'll think about other potential solutions.

[charlesvigneault]

Yes this is exactly what I did in the end.

I also read more of the doc and in my opinion RemoveByTag should be renamed to ExpireByTag and RemoveByTag should have the behavior I described.

The doc of Expire[Async]:

It is used to explicitly EXPIRE the value in the cache for the specified key.

But wait, what is the difference between Expire() and Remove()? With Remove() the value is actually removed, totally. With Expire() instead, it depends on how fail-safe is configured:

• if fail-safe is enabled: the entry will marked as logically expired, but will still be available as a fallback value in case of future problems
• if fail-safe is disabled: the entry will be effectively removed

Because right now the behavior of Remove and RemoveByTag is not consistent.

[jodydonetti]

Hi @charlesvigneault , this is something I thought a lot about, and made a couple of back and forth before going GA with v2.
Initially I wanted to create 2 methods, ExpireByTag() and RemoveByTag(), with the respective behaviours: the problem is that supporting both at the same time would have impacted performance in a non-negligible way. So I thought about having only the RemoveByTag(), but that would've been limiting. Then only ExpireByTag(), but in HybridCache the method is called RemoveByTag() and that may create expectations with users.
In the end, since the observable end result is the same for both, I opted for calling it in that way thinking that it had the best balance, all things considered.
I'm still trying to find a way to have both without affecting performance too much, and in that case I'll add the missing one.
Another option I thought about is to add the ability to specify the behaviour during the setup, so that it would be possible to define if RemoveByTag() would work as Remove or Expire.

[emeesterinterpulse]

Another option I thought about is to add the ability to specify the behaviour during the setup, so that it would be possible to define if RemoveByTag() would work as Remove or Expire.

This would work for us. If a TAG is removed the entries matching the tag is no longer valid. This prevents us from using failsafe at the moment.

[jodydonetti]

Hi @emeesterinterpulse , thanks for your input, I'm working on something, will update.