Using Domain Config UI creates *.yml files with duplicate UUIDs.

We also encountered this issue.
- set up domains on Drupal site's master branch.
- create new feature branch where you alter the site title, export the new config and commit.
- now go back to the master branch, and import config (here we tested something else manually that got merged to master)
- go back to the previous feature branch and try to import config, you get:

pc@pc:/var/www/html/ks-graphic.site (master =)$ lando drush cim
+------------+------------------------------------------------------------+-----------+
| Collection | Config                                                     | Operation |
+------------+------------------------------------------------------------+-----------+
|            | system.site::domain.config.dogbanner_localhost.system.site | Rename    |
+------------+------------------------------------------------------------+-----------+

 Import the listed configuration changes? (yes/no) [yes]:
 > y

 [error]  Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Rename operation for simple configuration. Existing configuration system.site and staged configuration domain.config.dogbanner_localhost.system.site. in Drupal\Core\Config\ConfigImporter->validate() (line 794 of /app/web/core/lib/Drupal/Core/Config/ConfigImporter.php). 

In ConfigImportCommands.php line 324:
                                                                                                                                                         
  The import failed due to the following reasons:                                                                                                        
  Rename operation for simple configuration. Existing configuration system.site and staged configuration domain.config.dogbanner_localhost.system.site.

This meant we could not import config anymore, so we had to remove this domain-altered config manually. Therefore, I'm raising priority because it could break the config deployment to QA and production sites.

Again, the same error I experienced when collegues changed the site name per domain and I tried to import config on a completely different site:

|            | domain.config.mezotrade_eu.system.site::domain.config.age_attraction_sk.system.site | Rename    |
|            | system.site::domain.config.age_attraction_sk.system.site                            | Rename    |
+------------+-------------------------------------------------------------------------------------+-----------+

 // Import the listed configuration changes?: yes.                                                                      

 [error]  Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Rename operation for simple configuration. Existing configuration domain.config.mezotrade_eu.system.site and staged configuration domain.config.age_attraction_sk.system.site.
Rename operation for simple configuration. Existing configuration system.site and staged configuration domain.config.age_attraction_sk.system.site. in Drupal\Core\Config\ConfigImporter->validate() (line 794 of /app/web/core/lib/Drupal/Core/Config/ConfigImporter.php). 

In ConfigImportCommands.php line 324:
                                                                                                                                                                                  
  The import failed due to the following reasons:                                                                                                                                 
  Rename operation for simple configuration. Existing configuration domain.config.mezotrade_eu.system.site and staged configuration domain.config.age_attraction_sk.system.site.  
  Rename operation for simple configuration. Existing configuration system.site and staged configuration domain.config.age_attraction_sk.system.site.                             

system.site.yml:

_core:
  default_config_hash: 5fiO5Le0rk-Y8-wpD231_eVHzGxPd2HtLK4cHmzZ2hw
langcode: sk
uuid: f4d6487a-1aec-48b6-9ddd-15a1c7595ded
name: 'Age attraction'
mail: mail@example.com
slogan: ''
page:
  403: ''
  404: ''
  front: /node/21
admin_compact_mode: false
weight_select_max: 100
default_langcode: sk
mail_notification: ''

domain.config.age_attraction_sk.system.site.yml:

_core:
  default_config_hash: 5fiO5Le0rk-Y8-wpD231_eVHzGxPd2HtLK4cHmzZ2hw
langcode: sk
uuid: f4d6487a-1aec-48b6-9ddd-15a1c7595ded
name: 'Age attraction'
mail: mail@example.com
slogan: ''
page:
  403: ''
  404: ''
  front: /node/21
admin_compact_mode: false
weight_select_max: 100
default_langcode: sk
mail_notification: ''

domain.config.mezotrade_eu.system.site.yml

_core:
  default_config_hash: 5fiO5Le0rk-Y8-wpD231_eVHzGxPd2HtLK4cHmzZ2hw
langcode: sk
uuid: f4d6487a-1aec-48b6-9ddd-15a1c7595ded
name: 'Mezo trade'
mail: mail@example.com
slogan: ''
page:
  403: ''
  404: ''
  front: /node/28
admin_compact_mode: false
weight_select_max: 100
default_langcode: sk
mail_notification: ''

We're using the Drupal 9.4.14 version with Domain 2.0.0-beta1, and have the same issue.

In general, I would say that the better practice is to add all 'domain.config.*' to the config_ignore.settings.yml and this also will resolve the issue.

However, I made a quick solution to resolve UUID duplicates.
It will be nice to test it.

Back to work cuz tests must be reviewed and fixed too.

Quoting configuration system maintainer @alexpott from #3405800-20: Config collections do not trigger configuration events consistently → :

Domain is not using its own StorableConfigBase object - see https://git.drupalcode.org/project/domain/-/blob/8.x-1.x/domain_config/s... - so it will trigger regular config events for it's overrides. Which is incorrect because as with config translations there are only partial representations of configuration and meant to be merged via the override system with active config in the default collection.

Are there prospects for a patch anytime soon?

I came here with the issue that on a site install with existing config and rename validation was thrown as described in the issue summary.
The steps are quiet easy to reproduce.

• Install a website
• Enable domain
• Add 2 domains
• Enable domain_config_ui
• Add language and domain context to system site page for domains
• Set config per domain per language
• Export config
• Try to reinstall site from config and it should fail

@HitchShock Thank you for the work in your MR. This looks like the way forward on fixing this issue.

Not sure how to write tests for site install with existing config.

But for everyone having this issue:

1. Use the patch from the MR
2. Delete the UUID from the config files and re-install
3. Save the config pages again and export config

MR is out of date and needs a refactor.

Marking as a fearure. Domain Config UI is a *convenience* module and experimental. Developers can work around this issue as noted or by using Domain Config directly.

Patch for 2.0-beta attached.

Re-rolled the patch against the latest dev 2.0.x.

#14 has described a workaround already (thanks Steffen!) and this is not breaking a site so decreasing issue prio...

Descriptions of the Priority → and Status → values can be found in the Drupal project issues → documentation.

The patch #31 worked for me and the UUIDs in the generated site config files for domains are different.

Happens to me on a brand new site with the very first configuration export and then the next import. This does seem site breaking IMO, because its really easy to walk into that and then get stuck.

Patch #31 alone throws this error:

ArgumentCountError: Too few arguments to function Drupal\domain_config_ui\Config\ConfigFactory::__construct(), 4 passed in /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php on line 259 and exactly 5 expected in Drupal\domain_config_ui\Config\ConfigFactory->__construct() (line 45 of /var/www/html/docroot/modules/contrib/domain/domain_config_ui/src/Config/ConfigFactory.php). #0 /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php(259): Drupal\domain_config_ui\Config\ConfigFactory->__construct()

Visiting the site shows:

The website encountered an unexpected error. Try again later.
Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service "domain_config_ui.factory", path: "options_request_listener -> domain.route_provider -> path_processor_manager -> path_processor_front -> domain_config_ui.factory -> exception.fast_404_html". in Drupal\Component\DependencyInjection\Container->get() (line 147 of core/lib/Drupal/Component/DependencyInjection/Container.php).
Drupal\Component\DependencyInjection\Container->get() (Line: 430)
Drupal\Component\DependencyInjection\Container->resolveServicesAndParameters() (Line: 237)
Drupal\Component\DependencyInjection\Container->createService() (Line: 177)
Drupal\Component\DependencyInjection\Container->get() (Line: 454)
Drupal\Component\DependencyInjection\Container->Drupal\Component\DependencyInjection\{closure}() (Line: 243)
Symfony\Component\EventDispatcher\EventDispatcher::Symfony\Component\EventDispatcher\{closure}() (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners() (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch() (Line: 241)
Symfony\Component\HttpKernel\HttpKernel->handleThrowable() (Line: 91)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 709)
Drupal\Core\DrupalKernel->handle() (Line: 19)

on Drupal 11.0.9.

Not sure what happened, but after removing the patch, clearing cache a few times, restarting ddev, re-applying the patch, the error does not occur anymore.

However it will still export with the same UUID until you have deleted all previously created records and flushed it out of Drupal, just a note.

Something in the way this patch handles UUIDs was causing fatal errors with Site Studio on importing new configuration with:

2024-12-19T15:10:04Z  [notice] Finalizing configuration synchronization.
2024-12-19T15:10:04Z In ConfigImportCommands.php line 291:
2024-12-19T15:10:04Z   The import failed due to the following reasons:
2024-12-19T15:10:04Z   Unexpected error during import with operation create for media.type.vector_
2024-12-19T15:10:04Z   image: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 's
2024-12-19T15:10:04Z   ource_uuid' cannot be null: INSERT INTO "coh_usage" ("s
2024-12-19T15:10:04Z   ource_uuid", "source_type", "requires_uuid", &quot
2024-12-19T15:10:04Z   ;requires_type") VALUES (:db_insert_placeholder_0, :db_insert_placehol
2024-12-19T15:10:04Z   der_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array
2024-12-19T15:10:04Z   (
2024-12-19T15:10:04Z       [:db_insert_placeholder_0] =>
2024-12-19T15:10:04Z       [:db_insert_placeholder_1] => media_type
2024-12-19T15:10:04Z       [:db_insert_placeholder_2] => media-mid
2024-12-19T15:10:04Z       [:db_insert_placeholder_3] => field_config
2024-12-19T15:10:04Z   )
2024-12-19T15:10:04Z   Unexpected error during import with operation create for field.field.media.
2024-12-19T15:10:04Z   vector_image.field_media_svg: SQLSTATE[23000]: Integrity constraint violati
2024-12-19T15:10:04Z   on: 1048 Column 'source_uuid' cannot be null: INSERT INTO "c
2024-12-19T15:10:04Z   oh_usage" ("source_uuid", "source_type", "req
2024-12-19T15:10:04Z   uires_uuid", "requires_type") VALUES (:db_insert_placeholder
2024-12-19T15:10:04Z   _0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placehol
2024-12-19T15:10:04Z   der_3); Array
2024-12-19T15:10:04Z   (
2024-12-19T15:10:04Z       [:db_insert_placeholder_0] =>
2024-12-19T15:10:04Z       [:db_insert_placeholder_1] => field_config
2024-12-19T15:10:04Z       [:db_insert_placeholder_2] => d38bcb72-e5ae-4e9a-99b8-3298da041238
2024-12-19T15:10:04Z       [:db_insert_p

These errors are very odd, because it implies UUIDs are NULL, when they aren't. So I went digging, and after removing patch #31, I couldn't get this error at all. Putting it back made it happen again.

I think it is because of this:

$originalUuid = $this->getOriginal('uuid', FALSE);

where it should be:

$originalUuid = $this->getOriginal('uuid', FALSE) ?? $this->get('uuid');

because according to getOriginal in Config:

   * Original data is the data as it is immediately after loading from
   * configuration storage before any changes. If this is a new configuration
   * object it will be an empty array.

originalUuid was coming up NULL for new configuration objects, where $this->get('uuid') was returning the UUID stored in the configuration yaml file. I am not 100% on all the things this patch is doing, but I think this is a potential problem which was hard to track down, but we need the functionality this patch provides (Domain specific config).

Attached is an updated patch with that change.

#14 so you are saying you have to delete the UUID manually every time from a domain.config.* file? The issue you linked to goes to a 404.

According to the README, UUID should not be copied into any domain.config* file. This seems like it could be a simple addition to the Domain module to prevent that from happening with:

declare(strict_types=1);

namespace Drupal\mymodule\EventSubscriber;

use Drupal\Core\Config\ConfigEvents;
use Drupal\Core\Config\StorageInterface;
use Drupal\Core\Config\StorageTransformEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

/**
 * Listen for configuration events and remove UUIDs from domain.config entities.
 */
final class ConfigExportSubscriber implements EventSubscriberInterface {

  /**
   * Handle the storage transform export event.
   *
   * @param \Drupal\Core\Config\StorageTransformEvent $event
   *   The event.
   */
  public function onStorageTransformExport(StorageTransformEvent $event): void {
    $this->removeDomainConfigUuid($event->getStorage());
  }

  /**
   * Handle the storage transform import event.
   *
   * @param \Drupal\Core\Config\StorageTransformEvent $event
   *   The event.
   */
  public function onStorageTransformImport(StorageTransformEvent $event): void {
    $this->removeDomainConfigUuid($event->getStorage());
  }

  /**
   * Remove UUIDs from any domain.config configuration entity.
   *
   * @param \Drupal\Core\Config\StorageInterface $storage
   *   The storage interface.
   */
  protected function removeDomainConfigUuid(StorageInterface $storage): void {
    $domain_configs = $storage->listAll('domain.config');

    foreach ($domain_configs as $domain_config) {
      $config = $storage->read($domain_config);

      if (isset($config['uuid'])) {
        unset($config['uuid']);
      }

      $storage->write($domain_config, $config);
    }
  }

  /**
   * {@inheritdoc}
   */
  public static function getSubscribedEvents(): array {
    return [
      ConfigEvents::STORAGE_TRANSFORM_IMPORT => ['onStorageTransformImport', -99],
      ConfigEvents::STORAGE_TRANSFORM_EXPORT => ['onStorageTransformExport', -99],
    ];
  }

}

is there any reason why this does not exist, or why I should not do this? The domain_config_test module includes several YAML files that also have no UUID with them.

For those having issues with Drupal 11, here is a temporary patch we are using until this issue is fully resolved.

Could this get rebased on latest 2.0.x-dev branch? There seems to be some conflicts.