Tagged cache namespace becomes partially stuck (Redis)

[GalahadXVI]

Laravel Version

12.41.1

PHP Version

8.3

Database Driver & Version

No response

Description

We are experiencing a situation where one specific cache entry stored under a Laravel Redis tagged cache no longer invalidates, while all other entries under the exact same tag set do invalidate as expected.

The issue began while running Laravel 11.47.0 and continues after upgrading to Laravel 12.41.0.
Because the problematic cache entry was originally created on Laravel 11, it is possible that the root cause occurred at write time on L11 and that the data became corrupted or desynchronised in a way that L12 cannot fix retroactively.

Cache store: Redis/Valkey 8
Tagged cache usage: Cache::tags(['character', 'character:progress'])->rememberForever(...)

Multiple keys exist under this tag set:
character:progress:data:web
character:progress:data:app

Calling cache::tags(['character', 'character:progress'])->flush(); should invalidate all cache entries under the same tag namespace. But only one of the keys under the tag namespace fails to invalidate.

The cache is invalidated only when underlying data changes. One day, entirely at random, one key simply stopped being invalidated while all others continued to behave normally.

The cache implementation worked correctly for approximately ~8 months without any failures.

No code changes, deployments, config updates, or environment changes occurred at the moment the problem began.

Updating to Laravel 12.41.0 did not resolve the issue. This might points to a stale or corrupted namespace generated on Laravel 11, or a deeper issue in the tag version logic.

To clarify, when running cache::tags(['character', 'character:progress'])->flush();:

• character:progress:data:web invalidates correctly and the remember() closure runs again on the next request.
• Other caches under the same tags also invalidate correctly.
• character:progress:data:app remains cached indefinitely and the remember() closure never executes again.
• No code I can run will invalidate the cache unless I manually tap into the valkey server and find it manually, or if I clear everything.

This happens despite having same code path, same cache store, same tags, and the same environment.

The only difference is the final cache key part (web vs app).

We fixed this issue by simply changing the tags from ['character', 'character:progress'] to ['character','character:progress:v2']

Steps To Reproduce

I think this issue is difficult to reproduce. Due to the nature of the issue, I cannot provide a deterministic reproduction script, but I hope the report helps surface potential edge cases in the tagged cache subsystem.

It is also entirely possible that the underlying cause has already been addressed in Laravel 12, and that the problem originated when the cache entry was written on Laravel 11. If the tag metadata became corrupted or desynchronised at write time, Laravel 12 would not be able to correct that retroactively.

Either way, I felt it was worth documenting.