Stale static cache - you're likely to have seen this bug!

This week I've finally found the core of several issues that I've had in the past. Are you using install-profiles or features? Then this bug is likely to have affected you too.

What is this all about?

The bug I am talking about is #1891356: Reset drupal static caches when a module is enabled or disabled. and was originally reported in January 2013 as a feature request.

When enabling a module drupal-core resets only some static caches (drupal_static()). Most of the caches - and all of those used in contrib - are not flushed. So in the same request after enabling a module, there might be some stale caches around. If you're using drush to enable modules or to install an installation profile all modules are enabled in a single "request". That means the caches are kept until the last module is enabled.

For the bug to show it usually needs at least two modules to be enabled in a single request. The first module asks for some information - initializing the cache. The second one tries to use the same information and gets the data from the stale cache thereby triggering an error / misbehavior. The problem that is actually triggered varies. That makes it particularly hard to track down.

I am a maintainer - is my module affected?

• Are you using features or ctools exports? -> your module is likely to be affected.
• Does your module implement hook_install() or hook_enable()? Are you using some other module's functions in those implementations? -> your module is likely to be affected

If you can answer all those questions with no - you're probably ok.

Are there workarounds?

The best solution for site-builders is to simply include the patch into their builds. This immediately removes all issues caused by the stale cache.

Depending on when during module_enable() the possibly stale cache is needed, there are workarounds. I'd recommend against randomly spawning cache-flushes all over contrib though and instead point users to the bug-report in the issue queue. If there is already some bug-report in the issue queue mark it as a duplicate of this issue.

How old is this bug?

I've seen the bug the first time at latest in March 2013, when developing pgbar. At least since then it's using _field_info_collate_types(TRUE) to refresh the stale field-type cache in pgbar_install(). In August 2014 - when working at #1681414: Enabling i18n modules fail in install profile I've finally begun to realize that this is actually a core issue: Why does a module that only implements a hook (and doesn't do any caching itself) need to take care of clearing the cache?

But this is not the first instance of this workaround. The oldest one, that I could find is in og-7.x-1.x dating back to November 2011.

The bug is probably as old as drupal_static() itself. Although I guess it was wanted behavior at some point.