It looks like you unchecked the "Allow edits from maintainer" box. That is fine, but please note that if you have multiple commits, you'll need to squash your commits into one before this can be merged. Or, you can check the "Allow edits from maintainers" box and the maintainer can squash for you.

Cheers!

Carsonbot

Unless I missed something, this would be very unsafe. If a tag expires before the items that are bound to it, said items won't be deleted when the same tag will be invalidated later on.

You're saying that tags remain in the storage while you deleted the users? How does that work? Reading the code, deleteItems calls sRem when deleting items, and Redis doesn't store empty sets. So I don't see how this can happen yet.

Unless I missed something, this would be very unsafe. If a tag expires before the items that are bound to it, said items won't be deleted when the same tag will be invalidated later on.

@nicolas-grekas I added a fail-safe mechanism to the code for this, so that the tag for an item can not have a lower lifetime than the item itself. See https://github.com/rebuy-de/symfony/blob/expire-redis-tags/src/Symfony/Component/Cache/Adapter/RedisTagAwareAdapter.php#L341-L344

You're saying that tags remain in the storage while you deleted the users? How does that work? Reading the code, deleteItems calls sRem when deleting items, and Redis doesn't store empty sets. So I don't see how this can happen yet.

Sorry for not being more clear on this. Le me try to explain how our current workflow looks like:

• User logs in
• We fetch the user from our external auth service based on the generated oauth token
• The result is then cached along with a tag. The cache item itself has a lifetime of 5 minutes

Now there are two possibilities where the cache (and/or tag) is explicitly cleared.

• The user logs out -> cache item will be cleared
• The user is deleted/disabled -> cache item will be cleared based on the tag

But if none of these two scenarios happen (e.g. because the user just left the website and is never coming back), the cache item will just expire after 5 minutes without the tag ever being deleted/expiring. And thats why we want to be able to define a lifetime for those tags.

Thanks that for the details.
The issue with adding an expiry to tag items is that Redis will flag them as volatile, which means they could be evicted while their corresponding items aren't.

Here is another idea: we could make the class implement PrunableInterface.
You would be responsible for calling prune() from time to time.
The implementation should be done in Lua ideally.

Would that make sense to you? Up to give it a try?

That sounds like a good alternative. I'll give it a try. Should I create a new PR or work on the new solution in this one?

A new PR would be fine, to keep this one for history.

Looking forward to your PR on the topic. Closing meanwhile, thanks for raising this point.

The cache tag's expire time should depends on the longest expire time key.
How about execute the lua script like this when sadd in \Symfony\Component\Cache\Adapter\RedisTagAwareAdapter::doSave:

local current_expiry = redis.call('TTL', KEYS[1])
if current_expiry > 100 then
   return 0
else
   redis.call('EXPIRE', KEYS[1], 100)
   return 1
end