Fix bugs in update path surfaced by config validation

Does it mean it needs to update dump or we can just add extra fixtures to existing dumps?

I have just found this issue after updated a project and realized that help_post_update_help_topics_search() created two configs without UUIDd that also made our strict QA pipeline fail, since the exported config in config/sync differs from the active config of clean site created via drush si -y --existing-config.

$ git diff
diff --git a/config/sync/block.block.claro_help_search.yml b/config/sync/block.block.claro_help_search.yml
index aca7524..6695d6d 100644
--- a/config/sync/block.block.claro_help_search.yml
+++ b/config/sync/block.block.claro_help_search.yml
@@ -1,3 +1,4 @@
+uuid: 17c15c63-085d-4ac2-aad3-a19746c37ccd
 langcode: en
 status: true
 dependencies:
diff --git a/config/sync/search.page.help_search.yml b/config/sync/search.page.help_search.yml
index 38d4344..b9b39a9 100644
--- a/config/sync/search.page.help_search.yml
+++ b/config/sync/search.page.help_search.yml
@@ -1,3 +1,4 @@
+uuid: 6f35532e-b3ab-4004-bfb2-db2b4482f004
 langcode: en
 status: true
 dependencies:

This also means that a UUID gets added to these config after a clean site install and can be exported to config/sync, but it would be beneficial if a follow up update hook would be added to fix the could-be-missing UUID problem on existing projects.

@mxr576 do you mean to add uuid generation to https://git.drupalcode.org/project/drupal/-/blob/10.2.x/core/modules/hel...

UUID generation was missing from there, indeed.
Now that the update hook is out, it can be fixed, but already updated sites will need a workaround for fixing the missing UUID.

In our case the CI prevented merging the change without a UUID, but others probably weren't that lucky.

Btw, should not config storage generate a UUID automatically when a new config is saved via standard API calls? Is there an issue for that already?

Maybe this would have been a scope of #2161149: Force-create new UUIDs in default config objects during initial import/creation → ?

Rediscovered this over in 🐛 Display title setting has wrong schema type Needs work where an update hook across all blocks fails because claro_help_search does not have a UUID in the fixture database.

The MR here fixes that, the uncompressed diff is:

--- drupal-10.3.0.filled.standard.php	2025-04-17 15:11:52.088063088 +0200
+++ core/modules/system/tests/fixtures/update/drupal-10.3.0.filled.standard.php	2025-04-17 15:10:53.921921024 +0200
@@ -2101,7 +2101,7 @@
 ->values(array(
   'collection' => '',
   'name' => 'block.block.claro_help_search',
-  'data' => 'a:11:{s:8:"langcode";s:2:"en";s:6:"status";b:1;s:12:"dependencies";a:3:{s:6:"module";a:2:{i:0;s:6:"search";i:1;s:6:"system";}s:5:"theme";a:1:{i:0;s:5:"claro";}s:8:"enforced";a:1:{s:6:"config";a:1:{i:0;s:23:"search.page.help_search";}}}s:2:"id";s:17:"claro_help_search";s:5:"theme";s:5:"claro";s:6:"region";s:4:"help";s:6:"weight";i:-4;s:8:"provider";N;s:6:"plugin";s:17:"search_form_block";s:8:"settings";a:5:{s:2:"id";s:17:"search_form_block";s:5:"label";s:11:"Search help";s:13:"label_display";s:7:"visible";s:8:"provider";s:6:"search";s:7:"page_id";s:11:"help_search";}s:10:"visibility";a:1:{s:12:"request_path";a:4:{s:2:"id";s:12:"request_path";s:6:"negate";b:0;s:15:"context_mapping";a:0:{}s:5:"pages";s:11:"/admin/help";}}}',
+  'data' => 'a:11:{s:4:"uuid";s:36:"356ded34-80b4-451a-bdc4-df8d8c0931e1";s:8:"langcode";s:2:"en";s:6:"status";b:1;s:12:"dependencies";a:3:{s:6:"module";a:2:{i:0;s:6:"search";i:1;s:6:"system";}s:5:"theme";a:1:{i:0;s:5:"claro";}s:8:"enforced";a:1:{s:6:"config";a:1:{i:0;s:23:"search.page.help_search";}}}s:2:"id";s:17:"claro_help_search";s:5:"theme";s:5:"claro";s:6:"region";s:4:"help";s:6:"weight";i:-4;s:8:"provider";N;s:6:"plugin";s:17:"search_form_block";s:8:"settings";a:5:{s:2:"id";s:17:"search_form_block";s:5:"label";s:11:"Search help";s:13:"label_display";s:7:"visible";s:8:"provider";s:6:"search";s:7:"page_id";s:11:"help_search";}s:10:"visibility";a:1:{s:12:"request_path";a:4:{s:2:"id";s:12:"request_path";s:6:"negate";b:0;s:15:"context_mapping";a:0:{}s:5:"pages";s:11:"/admin/help";}}}',
 ))
 ->values(array(
   'collection' => '',

Hm actually this isn't quite right, I edited the fixture by hand but I think it should be exported properly, this is what I get from trying to rush this while waiting at the airport gate to fly home from Dev Days.

Quite confused by this.

1. Using 11.x HEAD (9678f6309c8)
2. Revert \Drupal\FunctionalTests\Update\UpdatePathTestBase::$configSchemaCheckerExclusions as in the IS
3. Run core/modules/block/tests/src/Functional/BlockWeightUpdateTest.php, which uses drupal-10.3.0.filled.standard.php.gz.

Test passes. I expected it to fail.

1. I go through git history: find that 📌 Deprecate SyndicateBlock Active regenerated the dump (in May). I verify the uuid isn't there for block.block.claro_help_search.yml.
2. I add uuid as longwave did and compress again (without regenerating), so I'd expect the test failure now. It passes.
3. I think the array serialization needs {a:12 for the new element . Still passing.
4. I append to the test $this->assertSame('356ded34-80b4-451a-bdc4-df8d8c0931e1', Block::load('claro_help_search')->uuid());. I expected this to pass at this point, and it does.
5. I revert the changes to the gz. It fails: Failed asserting that null is identical to '356ded34-80b4-451a-bdc4-df8d8c0931e1'.
6. So at this point, means that the config validation is actually passing! ❓
7. I check uuid core data type schema, and see that Symfony's UuidValidator constraint actually allows null as a valid uuid 🤯

I'm wondering if we should add a not null contraint to the config entity uuid schema (maybe not here but in #2161149: Force-create new UUIDs in default config objects during initial import/creation → ?)

config_entity:
  type: mapping
  mapping:
    uuid:
      type: uuid
      label: 'UUID'
      constraint:
          NotNull: []

Hope this throws some light here, because I was really in the dark. But still don't know what's next.

And for the record, we need a explicit test for that uuid upgrade with a php fixture on top of drupal-10.3.0.filled.standard. If we add this directly to drupal-10.3.0.filled.standard.php.gz, any time it's regenerated for whatever reason, we would lose it as will not be hitting that concrete upgrade path referenced in #5.

Virtually all validators must allow NULL by default to avoid crashing hard on optional values.

I think you're right that we're missing a NotNull constraint. That's also what type: _core_config_info etc. do.

IIRC, alternatively, we could mark type: config_entity fully validatable — I vaguely remember that causing the NotNull constraint to be added automatically for required key-value pairs, and any type: mapping automatically gets all key-value pairs without requiredKey: false set to be required.
Yep, confirmed, see:

      if ($root_type_has_opted_in) {
        $data_definition->setRequired(!isset($data_definition['nullable']) || $data_definition['nullable'] === FALSE);
      }

— \Drupal\Core\Config\TypedConfigManager::buildDataDefinition()