cache.backend.chainedfast misbehaves when both fast and consistent backends point to the same storage

if the goal is to remove the usage of using APC you can achieve something similar using:

services:
  cache.backend.chainedfast:
    class: Drupal\Core\Cache\DatabaseBackendFactory
    arguments: ['@database', '@cache_tags.invalidator.checksum']

This will just replace the cache backend with the database one always.

Hmmm... drush and APC - this sounds like a CLI vs webhead issue.

Well, I'm seriously wondering whether its a good idea to use the same backend for both fast and non fast cache backend.

In theory the hosting environment though should be able to deal with APC in the first place.

Here is my theory why the snipped above isn't working at all, nor was ever tried out:

Given:

The fast chained backend doesn't implement cache tags support, but rather relies on a timestamp which is set, once any invalidation/set function is triggered.
In that case, the fast chained backend falls back to the less fast backend, which implements cache tags, so in theory cache tag invalidation continues to work.

What happens:

In the particular case above for entity types, we use a cache ID entity_type and the cache tag entity_types. We have the same cache backend injected for both the fast and the non fast backend. Given that we store cache entries in the fast backend with no cache tags, we override the entries in the non fast backend with cache tags. This results in having effectively no invalidations on the slow backend anymore at all, which results, in this particular example, that we retrieve a cache entry from before the invalidation, and by that an old list of entity types.

We could apply some level of validation: Don't inject the same cache backend twice into the chained fast backend. We could implement some level of invalidation on container build time, to tell people, that this is BS.

Just noting that #2722615: Chained fast caching interferes with field creation might be a similar bug report.

Per #2722615: Chained fast caching interferes with field creation, a more serious sort of misbehavior is that with the snippet in the OP added to services.yml, you can no longer create new fields on content types, block types, etc.... You get an error like this:

There was a problem creating field foo: Attempt to create a field field_foo that does not exist on entity type node.

Per #2722615: Chained fast caching interferes with field creation, a more serious sort of misbehavior is that with the snippet in the OP added to services.yml, you can no longer create new fields on content types, block types, etc.... You get an error like this:

Well yeah, I don't know who came up with that snippet in the first place, but its clearly just wrong. The only thing we can do is to check in the constructor,
when the two different backends are the same and throw some exception or so.

Would work for me, given it solves issues out there. Its still sort of a small BC break.

trigger_error() would avoid the fatal while still warning site owners that something is wrong. It's not impossible that this configuration could exist only on production via site specific services, so it'd be a nasty surprise if you updated and got this.

We could then change it to an exception another minor release out, since by then no existing installs should have the issue.

This is a good plan. Let's see when @penyaskito has time to do that.

/me shakes the head about 8MB, just 8MB, yes just 8MB

This addresses the feedback from catch, great!

Committed/pushed to 8.2.x and cherry-picked to 8.1.x. Thanks!

If you have the config in services.yml as mentioned in the IS then you can't upgrade from 8.1 to 8.2 as the first drupal_rebuild() will trigger_error which sends the logger into a circular dependency and thus the whole thing collapses with multiple fatals.

I can't reopen this one so I reopened the followup.

OPened #2808569: Ensure that ChainedFastBackend doesn't cause a fatal

We need to revert that one as well. I'm trying to write a regression test for that.

Here is kind of a start

This was released in 8.1.4 - people have either run into that regression and resolved it, or haven't upgraded yet. If they haven't upgraded yet, they're more likely to upgrade to 8.2.x when it comes out anyway.

So moving up to 8.2.x

Should we combine #27 and #15.

Re-rolled patch #27

Maybe this will fix test issue & also added an interdiff.

Hopefully this will solve the test issue & also added an interdiff.

Not sure what's up with the patch in #27 and rebases in #36, #39, and #41 - it looks to me like some unrelated test cases, and a test class for ChainedFastBackend that doesn't do anything yet.

----

#14 modified ChainedFastBackend, which appeared to cause problems and was reverted. Maybe still useful to be strict in ChainedFastBackend, but I think having ChainedFastBackendFactory handle checking that the configured backends are different would be safer.

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Think the issue summary needs an update.

Research why this happens and fix.

What was found and how was it fixed?

The approach in the merge request looks OK to me, but none of the previous attempts at test coverage will be relevant with that approach.

Attached patch against Drupal 10.1.x

@Yogesh Sahu, your patch looks like it's done a PSR-2 reformatting of the entire file, and it's unclear what changes your patch is based on.

Rebased the MR, and added tests for the ChainedFastBackendFactory class.

Seems close to ready just some CI failures in the MR

Hopefully just the quick fix to pass spellcheck

Removing issue summary update as that looks completed in #59

When I ran the tests locally without the fix

testIdenticalService failed with "Symfony\Component\DependencyInjection\ContainerInterface::get('cache.backend.test', 1): object was not expected to be called more than once." = GOOD

testDifferentServices = Passed.

Shouldn't both tests fail?

If I got that wrong then think this is good to be marked RTBC

testDifferentServices() uses the correct way to instantiate the factory, so should pass both before and after.

Committed 9124793 and pushed to 10.1.x. Thanks!