Problem/Motivation

Drupal changes the composer autoloader APCu cache prefix when a module is un(installed) and when the Drupal Core version is changed. It does not change, and the cache is not cleared, when code is added or removed from the vendor directory by composer.

This means classes that have been `class_exist` looked for previously, but are now added, are still not found. And would causes classes that have been previously loaded and removed still to have a location returned.

This was noticed by the strange behavior of geocoder plugins, where when their code dependency is installed with composer they aren't detected "How to add Gecoder 3.x providers" which as you'll see cause quite some confusion. The chanced upon solutions not being very clear in the comments: install some other module; allow access to, and visit core/rebuild.php; or clear APCu (by for example restarting webserver).

I added a comment on that issue that details some of the further issues, and where the core code is that makes the cache key.

Steps to reproduce

With APCu enabled. Either follow the geocoder example by adding a plugin after visiting the configuration page in the lifetime of the APCu cache; or similarly use code that checks if `class_exists` that does or does not, and add or remove as appropriate it using composer, and then check again.

Proposed resolution

No proposed resolution - yet - see first comment for thoughts.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

ekes created an issue. See original summary.

ekes’s picture

ekes commented
Issue summary: View changes

The first idea that jumps to mind is to in fact clear the cached autoloader results when clear cache is run. Something like:

  $class_loader = \Drupal::service('class_loader');
  if (($apcu_prefix = $class_loader->getApcuPrefix()) !== NULL) {
    apcu_delete(new \APCUIterator('/^' . preg_quote($apcu_prefix, '/') . '/'));
  }

This would already be a step forward? But it would only work from the web interface as mentioned in Drush's code here, you'd also have to run cache clear from the UI when you deploy code to another instance of the site [HT to instanceofjamie for pointing out, on Twitter where I first floated this issue, that it wouldn't help deployments].

The second idea is to include some unique value about the autoloader that composer has built. By running composer to add/remove the code the on disk autoloader has been updated. It even has a unique class name for the ComposerAutoLoaderInit (see vendor/autoloader.php). Would it be too much overhead to include that in the code that generates the prefix that Drupal uses?

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

ekes’s picture

ekes commented

Potential solution here: #3509069: Use a better container cache key

ekes’s picture

ekes commented
Status: Active » Closed (duplicate)

I'll close this in preference to above.

ressa’s picture

ressa
he/him
commented

Thanks for your thorough Issue Summary @ekes, and for guiding me to the #3509069: Use a better container cache key issue, I would never have found it without your help :)

In fact, I think it could be worth considering to add parts of this Issue Summary to the container cache key issue being worked on, to add some context. Or we can hope that people searching for a solution to the APCu cache challenge finds this issue, and get guided to it?