Clear APCu cache, if installed, after site-install command.

[bradjones1]

When re-installing a site, e.g. during local development, caches are not cleared. This makes sense in so far as database tables are dropped prior to install, and so most of Drupal's db-backed caches will be empty by definition. However, the chained fast cache backend uses APCu if present/available. This backend is used by, among other things, the extension list API for storing definitions of installed modules.

This can result in cache data inconsistency when, for instance, modules are excluded from export in $settings['config_exclude_modules']. If an excluded module is installed, and then the site re-installed, Drupal will continue to see a modules list from the APCu cache which includes the module, though it wasn't actually installed from config. An edge case for sure, but an edge case nonetheless.

This could theoretically extend to other cache backends such as redis/memcached/etc., however I think it makes sense to accommodate for this condition in Drush core because Drupal core itself supports APCu. The other cache backend types are in contrib-land and would thus be reasonable to place on the developer to lifecycle themselves.

[weitzman]

Alas that doesnt actually help with web requests. See #2450 (comment)

[bradjones1]

@weitzman I think we may be talking about different things? This is all at the CLI. The steps to reproduce are something like:

1. Have a dev-only module, let's call it module_dev. Include it in $settings['config_exclude_modules'] so it is not dumped to core.extension.yml on config export.
2. Enable the module, e.g. drush en module_dev. This busts the list of enabled extensions in the fast chained cache/APCu.
3. drush si --existing-config to reinstall the site - same container, no out-of-band cache clear of APCu.
4. drush en module_dev after re-installation returns [notice] Already enabled: module_dev.
5. drush cr
6. drush en module_dev now completes successfully.

The older MR you note above is for the cache clear command, not the installer... I'm guessing you noted that before commenting, though. Thoughts?

[bradjones1]

I appreciate the rubber-ducking; indeed, this was redis, not APCu. Sorry for wasting maintainers' time.