Flushing entries with 2 tags in RedisTaggedCache doesn't clean up properly

[emohamed]

It seems that Laravel's RedisTaggedCache doesn't clean up all tag references after an entry with multiple tags is deleted.

Example

redis-cli:

127.0.0.1:6379[1]> flushdb
OK
127.0.0.1:6379[1]> keys *
(empty array)

Tinker:

> Cache::tags(['db_results', 'expensive_queries'])->remember('some_query', now()->addHour(), fn () => 42);
= 42
> Cache::tags(['db_results'])->flush();
= true

redis-cli:

127.0.0.1:6379[1]> keys *
1) "laravel_database_laravel_cache_:63eb421571b75090852196:standard_ref"
2) "laravel_database_laravel_cache_:tag:expensive_queries:key"
127.0.0.1:6379[1]> get laravel_database_laravel_cache_:tag:expensive_queries:key
"s:22:\"63eb421571b75090852196\";"
127.0.0.1:6379[1]> smembers laravel_database_laravel_cache_:63eb421571b75090852196:standard_ref
1) "laravel_cache_:2127c624fcfcd7e3c9d0324c6a3f377772253589:some_query"
127.0.0.1:6379[1]> ttl laravel_database_laravel_cache_:63eb421571b75090852196:standard_ref
(integer) -1

It seems that the expensive_queries tag still remembers that some_query key is tagged, even though some_query is deleted.

In my use-case the keys are URLs, so some of them get quite big, causing the the left-over standard_ref key to get huge(> 1GB).

Note that standard_ref key doesn't have expiration, so the only way to delete those entries from the server would be to use scheduled command to go through all the tags and check which are not needed anymore. Or flush the database regularly.

---

Is this a bug in Laravel? Or I'm doing something wrong?

[henzeb]

never understood tagging anyway. But you have to flush using all the tags. if you tag something with ['db_results', 'expensive_queries'] you have to flush it with ['db_results', 'expensive_queries']

[emohamed]

@henzeb thanks for the suggestion. Flushing entries for both tags is a different operation. I think that that the framework shouldn't leave left-overs in the cache even when the entries are deleted by one of their tags.

[henzeb]

As I wrote: I never understood tagging anyway. Try it with arrays, it also leaves everything behind. even worse: when using tags, and the key does not exist, it creates the tag keys.

Config::set('cache.default', 'array');

Cache::tags(
    ['a', 'b']
)->put('c', 'd');

dump(Cache::tags(['a','b'])->get('c'));

Cache::tags(['a', 'b'])->flush();

dump(Cache::store());

you'll see c is still there. even when flushed with ['a', 'b']

tags are memory hogs and I do not want to use them.

[henzeb]

In laravel 10, they have rewritten things. I will test a few things when I arrive at work.

https://laravel.com/docs/10.x/upgrade#redis-cache-tags

[henzeb]

well, it is going better. previous versions indeed kept references to older versions of a key, when flushing one of the two tags, but in 10, you now have a sorted set for each tag. if I create key C in tags A and B, and I flush A, a sorted set for B will remain containing a reference to C, that no longer exists. It does not accumulate everytime I run the same code, but it doesn't go away either.

in addition, they added cache:prune-stale-tags, which I expected to make the sorted set for tag B to go away (or at least remove non-existent keys), but that doesn't happen.

to summarize:
When using tags in a situation where you use keys over and over again, it won't grow on you anymore.

When using tags where you have new random keys, this would still likely to grow.