So our cache invalidation by event does not play nicely - especially with Behat + goutte, but it's potentially racy.

When you invalidate caches by an event, any cache which is currently loaded is immediately cleared.
If another cache is later defined and instantiated, and it needs to be cleared, we clear that during instantiation of that cache.
Essentially, it's a lazy cache clear. All good so far.

To handle that process we make use of a timestamp, which is stored in each cache (could be a problem in itself). We compare this timestamp against the time that the cache was most recently cleared.

Unfortunately this timestamp is filled using the PHP time fucntion, which is only accurate to the nearest second.

If, as in the case of Goutte, you have many requests happening and they're in the same second, then the nearest second accuracy simply isn't good enough and you end up with some caches both cleared, and re-filled within the same second, but then being cleared again on the next request.

This isn't limited to Behat + Goutte of course - it will also be a problem in unit tests, web services, bulk actions, long-running queries, and even just on busy sites.

The initial fix is to switch to use microtime(true), but ideally there should be an invalidation token too so that we also invalidate on token change, and not just timestamp change

In theory it is a serious problem, but it's harder to tell in practice - it probably has limited effect because cache invalidation events are rarely used.

I detected this whilst tracking down random behat failures in a location which recently switched to using event purge by invalidation, and it was very time consuming to debug.