- π¬π§United Kingdom catch
When implementing this there's actually not really a race condition as described in #29.
If we implemented cache tag purging outside of drupal_flush_all_caches() then it would be possible for cache entries to exist with an 'incidentally matching' cache tag checksum. However, when we purge immediately after emptying the cache bins, there should be no cache entries created before the tags are purged, everything gets reset at the same time. There would have to be entries written literally during the purging itself for there to be a problem. This is about as likely as an entry being written in one cache bin that's just been emptied based on cached information in a table that's just about to be emptied - e.g. no worse than it is now.
So given that, what's in the MR might be enough.
- @catch opened merge request.
- First commit to issue fork.
- π¬π§United Kingdom catch
Probably the simplest solution here would be:
1. Add a CacheTagsChecksumPurgableInterface with a ::purge() method and implement it in the database backend.
2. Call this method on all cache_tags_invalidator services that implement the interface, as late in drupal_flush_all_caches as possible, definitely needs to happen after plugin caches are cleared, not sure whether before or after router rebuild or not.
3. Open a follow-up for the potential race condition described in #29.