Configuration synchronisation that both enables & configures a module fails and drupal_flush_all_caches()

Ran into this several times as well, first noticed this in 8.8.2

If it turns out to only affect Drush, let the maintainers know: https://github.com/drush-ops/drush/issues

Subscribing. Would be great if someone to have a check against Drupal Console which has similar commands to Drush.

This issue needs to be updated with Drush and console versions so that we can try to reproduce the issue.

I've tried to reproduce this on Drupal 8.9.x and Drush 9.8.0-dev and the jsonapi_extras module is been successfully installed and the overrides I've created are being imported.

Out of interest is the site in question using core provided caches or a something different?

Does it fail manually, or is it only with the build script? Might seem a stupid question maybe, but you never know something is going wrong in the build script (some leak somewhere, just a guess for now).

And it also fails with just core and json api only? Sorry for too much questions, just trying to isolate :)

The reason I'm asking is because something else might be in the way, e.g. some other config module or so, maybe even custom code?

I'm afraid that one of those additional config (or maybe a combination) modules will cause the fail.

#23 Doesn't entirely prove that configuration import is failing, it proves that the tab for jsonapi_extras isn't showing up after configuration import.

For example if drush cex doesn't show any changes, then the configuration import probably finished successfully.

Can you try things like going to /admin/config/services/jsonapi/extras directly?

I can repeat the test but it only occurs for me on Drush 10 and not Drush 9. That's still not saying this is Drush's fault but there is something different in the way that D9 and D10 do things that's resulting in this bug.

On D10 the module is installed and there are no config changes to import but the route doesn't work and even doing a cache rebuild via the UI doesn't work. I considered that maybe this was something in APCu so I disabled that - didn't fix it either. V interesting.

So one sign of the problem is that jsonapi_extras has not made it into the container.modules parameter. Which is why it's not in the router.

So the patch attached allows drush cache-rebuild to fix the problem but it doesn't actually fix the problem on import.

Ok I know what has broken this in Drush. For some reason they've decide to use the UpdateKernel for running config import. Core does not do this and have no idea why they've chosen to do this. Here's one possible fix for Drush - just don't use the update kernel. Config updates are not database updates they are not meant to use that kernel. An alternative approach would be to force flush all the caches after config import. Note that core does not do this because it is not necessary because it uses the regular kernel.

@BramDriesen that's a patch for Drush that fixes the issue. It'll never pass on core :) and Drush works via github. The issue that has caused this problem is https://github.com/drush-ops/drush/pull/4217

Here's a fix for #27. I think this change makes sense as it means that the module list is coming from a single source of truth and that's the extension.list.module service.

Here's test coverage.

Updated the issue summary to reflect the solution and where the real problem is. This patch is a mitigation the real fix has to be in Drush 10 and Drupal Console.

Test failures in 36, against 8.9.x and 9.0.x are real - couple of different ones.

Ah yeah we'll need a different patch for 9.0.x because path_alias is not always installed there.

I don't think the test failure against 8.9.x is real - that's from Tuesday and one of HEAD fails that day but the 9.x one is real. Here's new patches. the 8.x patch is the same as #36.

The fix looks good, tests look good for their respective versions.

+++ b/core/includes/common.inc
@@ -550,12 +550,15 @@ function drupal_flush_all_caches() {
   foreach ($module_data as $name => $extension) {

Not visible in the patch, but for reference, that variable comes from above:

$module_data = \Drupal::service('extension.list.module')->reset()->getList();

Committed/pushed to 9.0.x, 8.9.x, and 8.8.x, thanks!

Thanks to everyone for the quick turn around on this issue. It was a major pain-point for our team recently. Very appreciated!

I just encountered this importing configuration into an existing Drupal 9.2.6 site, which enabled a module and its configuration. I got this error after running drush config:import:

The configuration cannot be imported because it failed validation for the following reasons:
Unable to install the field_defaults module since it does not exist.

#3247659: Can't import configuration

If I cleared cache in advance, the import went through smoothly:

drush cache:rebuild
drush config:import
[...]
[notice] Finalizing configuration synchronization.
[success] The configuration was imported successfully.

Lando          : 3.4.2
PHP            : 7.3.31
Drupal version : 9.2.6
DB driver      : pgsql
Drush version  : 10.6.0

That's a great idea @BramDriesen! I have created #3247786: Configuration import with new module fails, unless cache is rebuilt beforehand.