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

Roman Zimmermann's picture
Roman Zimmermann

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.

Share this!

Comments

Thanks for sharing. A lot of time has been wasted on building workarounds for this.

Thanks for sharing.

Question:
I'm a bit confused. Is #1891356 issue D8 related or it's also D7 related?

Roman Zimmermann's picture

This issue is present in both D7 and D8. Due to Drupal's current release policy any fix has to go into D8 first. So it will take a while before we see any fix in D7.

Pages