Missing plugin notice after every merge and cache clear, cache_discovery table

We need the full backtrace of that, enable verbose error logging.

\Drupal\Core\Entity\Plugin\DataType\Deriver\EntityDeriver::getDerivativeDefinitions should populate the bundle-based plugins, no reason why that shouldn't be there. Could be some really weird race condition.

I don't think this is a cache problem, but either the entity or typed data systems that just use cache, like everything else in Drupal.

Only idea I have right now is to add some debugging in there, if at the end of that loop you don't have the definition for node:gbe in there, log the backtrace to see how/when the cache is rebuilt.

Also, when this happens, what does getBundleInfo() return? Maybe there is a bad alter hook for either typed data or bundle info that's messing with the built definitions.

I'm experiencing a very similar problem. I enable a module via CLI and cache_discovery isn't being updated and module fails through the UI (appears checked on module page, no routes, php errors for class discovery, etc).
This _only_ happens on my live environment though... works fine in local development and PR built environments. May be due to a PHP configuration difference between them?

I _think_ there is a race condition between an APCU cache and the database cache. The action of changing a module status is unstable (will enable, but menus won't show, classes will fail, etc) unless I clear all cache_ tables manually and force an APCU cache clear.

Perhaps related to #2347867: Race conditions with lock/cache, session storage - add a non-transactional database connection where the database cache items are held up in a transaction, but other cache backends are not, leading to possible coherency issues?

Just to mention that we had this issue showing up only when clearing with drush using the 10.3.6 version, but got fixed using ^10.6.

We're encountering the same issue on one of our sites. On our production environment, after clearing caches, a couple users get fatal errors. Here's a couple of those errors with full stack traces:

• https://sentry.io/share/issue/f5fd52104e1b410b8c05b6e0ca18c0b1/
• https://sentry.io/share/issue/89e35fcd9b22479d9874d7f844b31c60/
• https://sentry.io/share/issue/ed438d1eacfd4759966e5a51fc26263b/

The situations in which these errors seem to happen vary a lot, the only thing they have in common is the cache rebuild that just happened. I think the fact that we're only encountering this on our production environment is because only there people are still using the site when we're clearing caches.

Just to mention that we had this issue showing up only when clearing with drush using the 10.3.6 version, but got fixed using ^10.6.

We're using the latest Drush 11, still encountering the issue

Perhaps related to #2347867: Race conditions with lock/cache using non-database storage - add a non-transactional database connection where the database cache items are held up in a transaction, but other cache backends are not, leading to possible coherency issues?

We're only using standard database storages.

I noticed we were only getting these kind of errors for ECK entity types. Turns out eck_entity_type_build was not being invoked in certain situations, causing all ECK entity types to be missing. I then found #3207813: ModuleHandler skips all hook implementations when invoked before the module files have been loaded, and it looks like the latest patch from that issue fixes this issue for me.

I am wondering if we are seeing the same issue in #3260465: \RouteNotFoundException: Route "entity.node.vmd_preview_list" does not exist., it seems that conditions exist that allow dynamically defined routes via "DeriverBase" classes to be passed over before the available plugins list is cached.