Misleading warning (?) cache.WARNING: Failed to save key "mystringtags" of type integer.

[rbaarsma]

Symfony version(s) affected: 4.4.1

Description
I see this warning in the logs:

cache.WARNING: Failed to save key "stream.thiemo_sysnat_e9_v4-publish-1573137262tags" of type integer. {"key":"stream.thiemo_sysnat_e9_v4-publish-1573137262\u0000tags\u0000","exception":null}

The real problem is probably (?) that I'm trying to invalidateTags where the tag does not exist, but the warning message is not even close to telling me that.

How to reproduce
I'm using both doctrine ORM and doctrine ODM, and re-using the doctrine ORM cache pool to store ODM result cache manually

framework:
    cache:
        pools:
            doctrine.result_cache_pool:
                adapters:
                    - cache.adapter.array
                    - cache.adapter.apcu
                    - cache.adapter.redis
                tags: true

At some point I invalidate tags, but it is possible that the tag has not been created

        $this->doctrineResultCachePool->invalidateTags([
            sprintf('%s-%s-%d', $code, $type, null), // latest version
            sprintf('%s-%s-%d', $code, $type, $revision), // specific revision
        ]);

That's when this message shows up.

Interestingly enough I get 4 warnings, two for each tag. Perhaps the tag was in redis, but not in this pod?

Possible Solution
Improved warning message that I've tried to invalidate a tag that does not exist.

[nicolas-grekas]

I'm not able to reproduce the warning. When an item is not found, invalidating it doesn't trigger the warning unless the tag cannot we written (invalidating writes to the pool).
Can you provide a reproducer we could clone locally? That'd allow understanding what's going on.

Status: needs feedback

[rbaarsma]

I've just got reports that the cache is not invalidating properly. I'm afraid that the tags are indeed not saved. Possibly the warning is correct, although I've yet to find out why the cache entries are written correctly, but the tag cache entries are not. Perhaps one of the caches is not able to process the null byte (\u0000)?

Perhaps the bug description is wrong, but it's a bug in saving tags instead.

I'll try to further debug this later this week.

[rbaarsma]

I've found the issue.

Using a cache chain with tags is not a good idea without using a cache_pool

The problem is that the tags are stored in the different levels of the cache chain and when invalidating tags, the tags might not even exist in the specific part of the cache we are looking in. Even when we clear it for that specific cache (ex. invalidate a tag within apcu), it is not invalidated in Redis too.

When I introduced a cache_pool for the tags, all was ok.

framework:
    cache:
        pools:
            my_taggable_cachepool:
                adapters:
                    - cache.adapter.array
                    - cache.adapter.apcu
                    - cache.adapter.redis
                tags: tag_pool
            tag_pool:
                adapters:
                  - cache.adapter.array
                  - cache.adapter.apcu
                  - cache.adapter.redis

Perhaps it's a good idea to either introduce an error message when trying to configure a cache pool with tags: true and multiple adapters, and/or add a warning to the docs.

[nicolas-grekas]

Your findings are correct!
Would you be able to work on improving this?

[rbaarsma]

Yes, but I'm not very familiar with the DI Passes and stuff. Could you give me a hint what is the best place to throw an exception.

Basically I want to throw an exception if someone tries to configure a cache pool with multiple adapters and tags: true (not a tags cache pool)

Also that might be construed as a breaking change.. since it might pop up for people who have not noticed this bug and are using a chained adapter with tags this way. In my opinion the error would help them resolve a bug in their code, but not sure how you stand on the BC break on that.
I guess we could potentially put a deprecation warning and hard error in SF5 to avoid problems.

Alternatively I could look at contributing to the docs, never tried that either :)

[xabbuh]

@rbaarsma I could look into it but I am not sure if I really understand what was the initial issue here. Can you elaborate bit on that?

[nicolas-grekas]

Can you please confirm the patch on ChainAdapter in #36555 fixes the issue?