\Drupal\Core\Recipe\ConfigConfigurator unsets the uuid of active configuration, but it should only do that if the recipe data does not contain a UUID

Related, but not the same: 🐛 Drupal does not recognize when the config is identical Active .

Don't see anything to review?

FYI this would allow XB's test recipes to become more reliable:

diff --git a/tests/fixtures/recipes/test_site/recipe.yml b/tests/fixtures/recipes/test_site/recipe.yml
index c776203de..d476bf6a1 100644
--- a/tests/fixtures/recipes/test_site/recipe.yml
+++ b/tests/fixtures/recipes/test_site/recipe.yml
@@ -8,10 +8,6 @@ install:
   - xb_test_sdc
   - xb_dev_standard
 config:
-  # Loose config imports because the code components in `xb_test_code_components` contain UUIDs, which are used to
-  # generate corresponding assets on disk with predictable names.
-  # @todo Change to `strict: true` after core bug https://www.drupal.org/project/drupal/issues/3532271 is fixed.
-  strict: false
   import:
     experience_builder: '*'
     system:
… which should also make things for Drupal CMS a whole lot more predictable :innocent: 

And I can't imagine us being the only ones affected, so bumping priority 😇

How did I end up reporting this?

See #3532130-11: `/xb/api/v0/config/component` crashes when `article` node type does not exist due to hardcoded assumption in `GeneratedFieldExplicitInputUxComponentSourceBase::getClientSideInfo()` → for what prompted me to add strict: false to XB's test site recipe and also prompted the creation of this issue.

The 3 commits before that comment show what had to change.

The problem IIRC is that the recipe system when strict: true (the default), the comparison of the UUID stored in tests/fixtures/recipes/test_site/config/experience_builder.component.js.xb_test_code_components_using_imports.yml fails to match the active one.

Is there any reason we shouldn't just unconditionally remove the uuid and _core keys from the incoming recipe data?

The recipe system assumes those keys aren't there, but that's not a safe assumption -- lots of people make that mistake. We definitely do not want to have those keys be considered in the comparison.

On the other hand, we could remove those keys from the recipe data during the comparison, but if the recipe still has those keys, they'll get imported anyway...which could be bad.

I think what needs to happen here is that RecipeConfigStorageWrapper should unconditionally remove those keys from any config it reads in. Either that, or the FileStorage object created by \Drupal\Core\Recipe\ConfigConfigurator::getConfigStorage() needs to do it.

the recipe data contains a UUID (which is not a best practice, but it's also not forbidden, and sometimes, there may be a good reason for it)

Wim, can you elaborate on this bit? It's not forbidden but that might just be an oversight on our part. What are some good reasons for a recipe to include config UUIDs?

What are the rare cases where you would want/need the UUID in a config?

#9++

(which is not a best practice, but it's also not forbidden, and sometimes, there may be a good reason for it)

What I meant is that config exported as default config into a module is (AFAIK) supposed to NOT have a UUID — default config in modules is supposed to get random UUIDs generated — because all that should matter is the config entity ID (a machine name), not the UUID.

What are the rare cases where you would want/need the UUID in a config?

See XB's \Drupal\experience_builder\Entity\XbAssetLibraryTrait::getJsPath() — where it needs to generate a predictable file name based on the config entity UUID.

Lots has changed/been improved/hardened in XB itself and in Drupal core 11.2 — this issue was created before 🐛 PHPUnit Next Major tests failing Active landed, so first double-checking whether this is truly still needed. Although … #9 will definitely remain true 😇, but then it probably would only be .

Doing that double-checking in 📌 Try making XB's `test_site` Check if #3532271 is still blocking Active …

Setting strict: true still causes the recipe to fail (but now on a different piece of config). Quoting #3542282-3: Try making XB's `test_site` Check if #3532271 is still blocking → :

Error: Command failed: sudo -u www-data DRUPAL_DEV_SITE_PATH=sites/simpletest/42352967 php core/scripts/drupal recipe /builds/project/experience_builder/_drupal/web/../web/modules/contrib/experience_builder/tests/fixtures/recipes/test_site
In ConfigConfigurator.php line 68:
                                                                               
  The configuration 'experience_builder.xb_asset_library.global' exists alrea  
  dy and does not match the recipe's configuration                             
                                                                               
recipe [-i|--input INPUT] [--] <path>
    at ChildProcess.exithandler (node:child_process:422:12)
    at ChildProcess.emit (node:events:517:28)
    at maybeClose (node:internal/child_process:1098:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:303:5)
    at Process.callbackTrampoline (node:internal/async_hooks:128:17) {
  code: 1,
  killed: false,
  signal: null,
  cmd: 'sudo -u www-data DRUPAL_DEV_SITE_PATH=sites/simpletest/42352967 php core/scripts/drupal recipe /builds/project/experience_builder/_drupal/web/../web/modules/contrib/experience_builder/tests/fixtures/recipes/test_site',
  stdout: '',
  stderr: '\n' +
    'In ConfigConfigurator.php line 68:\n' +
    '                                                                               \n' +
    "  The configuration 'experience_builder.xb_asset_library.global' exists alrea  \n" +
    "  dy and does not match the recipe's configuration                             \n" +
    '                                                                               \n' +
    '\n' +
    'recipe [-i|--input INPUT] [--] <path>\n' +
    '\n'
}

— https://git.drupalcode.org/project/experience_builder/-/jobs/6267192#L1235

(That's the test results for https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...)