As a matter of fact when you declare a new pool with tags but without an explicit adapter it will fallback here to use app.cache as the adapter: https://github.com/symfony/symfony/blob/7.2/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php#L2404

This wouldn't throw the deprecation, but manually specifying that behaviour will throw the deprecation.

Ok i'm really questioning what was the original goal here, as the tests show you can not configure the cache.app pool manually as that is reserved, I guess the whole deprecation can be removed and we are better off reverting the original PR

the only thing I imagine that could trigger the original issue then would be manually decorating `cache.app and I'm not sure if symfony should check this, or where to best check this, but it can not happen in the framework extension 🤔

We had set framework.cache.app set to use cache.adapter.redis_tag_aware, which Symfony allowed just fine, but that makes cache.app TagAware. Which is also fine, until you also start using Twig Caching, which wraps app.cache and make it tag aware, so it becomes tag aware "twice" and Twig caching doesn't work at all, but there is no indication anywhere that it doesn't work. It just MISSes all cache fetches, there are no exceptions, no warning, no nothing, it just doesn't work, and if you don't look close enough you'll never know.

So yes, there is a real use case here that this solves.

i guess i see, but that is not what was deprecated, because what was deprecated was using cache.app as adapter in any tagged pool, let me try to adjust the test case to your example

Changed the deprecation now that it checks for framework.cache.app and framework.cache.system as well, as both hard code tags = false so it makes no sense to configure them as tag aware right?

And now I understand also using cache.app.taggable as alternative, that makes only sense when using that service somewhere, but not on adapter level

Ok now apparently there are other test cases that expect that one can use cache.adapter.redis_tag_aware for cache.app 😮‍💨

Changed the deprecation now that it checks for framework.cache.app and framework.cache.system as well, as both hard code tags = false so it makes no sense to configure them as tag aware right?

Given the full context, indeed it does not. However, when you don't have the full context and are just configuring stuff in framework.yaml there is no way to know that app cache must not be taggable 🤷

Closing this as the behaviour in question is covered by test, instead I've now opted for removing the deprecation as that was quite clearly wrong.

see #58950