Revert Redis Tagged cache implementation

[AidasK]

Laravel Version

10.x & 11.x & 12.x

PHP Version

8.x

Description

It's well known that laravel tagged cache was removed from the docs a couple of months ago and it looks like a too harsh of a decision for a feature which was in the core for 10 years. So I would like to propose an alternative approach which would not require a lot of work from the devs.

I suggest to revert laravel redis tagged cache to 9.x version. It had no bugs with consistency. It always worked while flushing the tagged cache and it always returned the fresh data. Of course it had leaks, but it was not causing the application to misbehave. This feature was in laravel core for 10 years now and for most of us it was usable. So old implementation can still be used, but some caution messages should be added to the docs.

So my suggestion is to:

• Bring back the docs.
• Revert implementation for redis to 9.x or even better to use Symfony Cache which supports tags.
• In case of 9.x, mention that tagged cache does not flush the tag keys and values and they might build up over time. So tagged cache should not be used with dynamically created tags. E.g. used id should not be used as a tag. Though tag cache won't be a problem if it's used with static code enums or constants as they don't scale infinitely.
• In case of 9.x, add a requirement to always use an expiry date with the tagged cache to prevent running out of memory. So instead of using cache forever, you should cache only for one week or a month.

So old tagged cache is still usable, though developers have to be aware of the shortcomings. At current state redis tagged cache is unusable as it does not guarantee consistency so memory leaks are not even a concern if it's not working.

Steps To Reproduce

#48078

laravel/docs@63dde39

[jspicee]

Revert implementation for redis to 9.x with warnings would be the best for me

[binaryfire]

This was my reply to Taylor in the docs commit:

We have loads of apps that rely on cache tags.... It's a crucial feature for managing caching in any large scale app, or multi-tenant setups etc.

If you're open to breaking changes in v11, I think refactoring tags to work how they do in every other platform (i.e. much more simply) would be great. The complexity in Laravel comes from how multiple tags work. The readme of this package explains it well: https://github.com/swayok/alternative-laravel-cache.

I never understood the logic behind Laravel's implementation. Tags should be independent - i.e. you can tag a single cache object with multiple tags, then purge that object using any of those tags. So you could tag a post with posts and tenant_1, and if you purged either the posts or tenant_1 tag that object would be removed.

[AidasK]

Laravel follows https://www.php-fig.org/psr/psr-16/ e.g. SimpleCache interface while symfony follows PSR-6, which is compatible with psr-16. So it should not be hard to write a driver as explained here https://laravel.com/docs/11.x/cache#writing-the-driver

As for tags, laravel has not documented how to extend them, but it's actually quite simple. Instead of extending the Illuminate\Contracts\Cache\Store; contract, you should extend Illuminate\Cache\TaggableStore and override tags method with symfony tags implementation.

So it's actually not that hard to solve and IMO this solution should be a good replacement for laravel native cache implementation.

[eldair]

This is what I came up with today, it might be helpful to someone (ofc every input is appreciated) https://github.com/eldair/laravel_symfony_cache/tree/main/extensions/SymfonyRedisCache
I took some ideas from https://github.com/1FF/laravel-mongodb-cache

[eldair]

I had to make changes to clean keys because laravel doesn't follow ether psr-6 or psr-16 when it comes to cache keys - laravel uses : for various internal cache keys (like maintenance mode) which is not allowed by both PSRs.

[gerardnll]

Thanks for the implementation! Is it me or setting \INF when calling ->get() (https://github.com/eldair/laravel_symfony_cache/blob/main/extensions/SymfonyRedisCache/RedisTaggedCache.php#L64) makes the cache revalidate always? Maybe you want to set 0 although that would disable the probabilistic early expiration.

[eldair]

It should recalculate since it is in put method, if it doesn't recalculate and the item with that key already exists it will not be updated to the desired value from put method.

[skills-up]

Has a decision been reached on this yet?

I'm a developing a multi-tenant SaaS application, and imagine my surprise when the tags suddenly went missing from the docs.
At this point, I'm unsure of their availability in the framework, and afraid to use them even if supported.

A tagged cache is required for some significant chunks of data, that are rarely updated. I would like to cache them all forever, and flush the cache only when any corresponding entry is updated.

[henzeb]

Not sure how you've set them up. if you have multiple tags, I can't help you atm, but maybe you could try https://packagist.org/packages/henzeb/laravel-cache-index

[wilsenhc]

Thank you @henzeb, just saved my life! I will take a better look at the source code later and contribute with anything I can!

[byErikas]

bumping this

[pelmered]

I really hope this is being worked on for the Laravel 12 release. It is a critical feature for a lot of applications.
Something based on symfony/cache with Laravelified API would be a great solution IMO.

[therecluse26]

Why are there still crickets from the Laravel team on this? At the very least, tell us ye or nay if you're planning updates to this functionality, or if we should pound sand and find an alternate solution

[byErikas]

since this seems a little dead in the water, I made a solution that implements cache in the classic way, but it has possible pitfalls. You're free to try it but read the Readme beforehand. https://github.com/byErikas/cache-tags

It works for my needs, doesn't override too much logic too.

[skills-up]

My usecase is very simple, and I guess very common. I've a multi tenant system, where each tenant has their own cached items, with common entity (and thus key) names. I need to scope key by tenant to avoid cross read/write. The primary use of cache here is to cache large reports that require a lot of calculations. These reports caches are tagged by all contributing entity names, so that when an entity changes I'll purge cache tagged with that entity name, and expect all corresponding caches to be cleared. Almost everything is cached forever as well.

[binaryfire]

These reports caches are tagged by all contributing entity names, so that when an entity changes I'll purge cache tagged with that entity name, and expect all corresponding caches to be cleared.

Laravel's cache tagging never worked like that (although I agree it should have - see my comment here). If you tag an item with 3 tags, you can't purge that item using just one of the tags. You need to pass in all 3.

If you want "tag-with-many / purge-by-any" you're going to need something like Erikas' solution. But it needs set garbage collection. It shouldn't be too difficult to port over the logic from #45690.

[byErikas]

These reports caches are tagged by all contributing entity names, so that when an entity changes I'll purge cache tagged with that entity name, and expect all corresponding caches to be cleared.

Laravel's cache tagging never worked like that (although I agree it should have - see my comment here). If you tag an item with 3 tags, you can't purge that item using just one of the tags. You need to pass in all 3.

If you want "tag-with-many / purge-by-any" you're going to need something like Erikas' solution. But it needs set garbage collection. It shouldn't be too difficult to port over the logic from #45690.

Laravel has garbage cleaning mostly taken care of. From my understanding, artisan cache:prune-stale-tags gets tag sets, checks if inner items are expired, and, if so, wipes the set. I have the job set to run every once a day, and memory use seems reasonable.

[binaryfire]

If you've made your implementation compatible with flushStaleTags() then yeah, the default prune command should work. Might be worth adding some test cases to your package to make sure? That's something you really want to ensure is working properly.

[skills-up]

These reports caches are tagged by all contributing entity names, so that when an entity changes I'll purge cache tagged with that entity name, and expect all corresponding caches to be cleared.

Laravel's cache tagging never worked like that (although I agree it should have - see my comment here). If you tag an item with 3 tags, you can't purge that item using just one of the tags. You need to pass in all 3.

If you want "tag-with-many / purge-by-any" you're going to need something like Erikas' solution. But it needs set garbage collection. It shouldn't be too difficult to port over the logic from #45690.

I think this explain certain bugs I had struggled to fix a few years back 😢

[taylorotwell]

I would be open to solving the Redis "forever" leaking problem if someone has a clean way to do it. The only way I know of to solve it is by maintaining a list of entries somewhere in the cache?

[pelmered]

That sounds great!

I think something on top of Symfony Cache that has good support for tags would be a good way forward.
I guess they have solved the memory leak problem as well?

[doxroot]

for people who need something very simple for Redis

https://github.com/doxroot/laravel-redis-cache

is just a simple wrapper, Laravel already come with all needed for this. However, i use this code above to have a simple way of deleting multiple redis keys if i need.
is not a real tag implementation, again is just a wrapper around powerful Laravel cache system.

Some apps may need something like tag-name:filter-name:key
So with Redis then is simple to delete all keys like tag-name:* or tag-name:filter-name:*

Not something fancy, but it works for my needs. (hope it can help others)

[charescape]

Considering rapid implementation along with long-term stability and maintainability, it might be a better solution to build Laravel's cache based on the composer require symfony/cache component. It is recommended to introduce symfony/cache in Laravel 14.