Changing domain config requires a manual cache rebuild to become active

Hi @idebr, I haven't been able to reproduce the problem locally.

Could you try to provide a test that reproduces your problem?

Thanks @idebr, will have a look at it.

Root cause analysis

When system.site is saved through Drupal's normal admin form, core's \Drupal\system\EventSubscriber\ConfigCacheTag::onSave() listens for ConfigEvents::SAVE and invalidates the route_match and rendered cache tags. This is what causes the RouteProvider's cached route collections to be cleared, so that PathProcessorFront re-resolves / to the new front page path on the next request.

However, when domain config overrides are saved via DomainConfigOverrideEditable::save(), the event dispatched is ConfigCollectionEvents::SAVE_IN_COLLECTION — not ConfigEvents::SAVE. Core's ConfigCacheTag only subscribes to ConfigEvents::SAVE, so it never sees domain override saves.

The consequence is:

1. Admin changes the domain front page from /node/1 to /user via the UI
2. DomainConfigOverrideEditable::save() writes the new value correctly and invalidates config:system.site
3. On the next request to /, RouteProvider::getRouteCollectionForRequest() finds a cache hit (tagged with route_match, which was not invalidated)
4. The cached route collection still contains the old resolved path (/node/1)
5. PathProcessorFront::processInbound() is never called — the RouteProvider skips inbound path processing on cache hit
6. The old front page is served until a manual cache rebuild

Fix

New event subscriber DomainConfigCacheTag that listens for DomainConfigOverrideEvents::SAVE_OVERRIDE and DELETE_OVERRIDE, and delegates to core's ConfigCacheTag::onSave() by wrapping the domain override in a ConfigCrudEvent. This works because DomainConfigOverride extends Config which extends ConfigBase, so it's compatible with ConfigCrudEvent's constructor.

This way we don't duplicate core's logic — any future changes to ConfigCacheTag::onSave() (e.g. handling additional config names) will automatically apply to domain config overrides too.

Changes

New file: domain_config/src/EventSubscriber/DomainConfigCacheTag.php

class DomainConfigCacheTag implements EventSubscriberInterface {

  public function __construct(
    protected ConfigCacheTag $configCacheTag,
  ) {}

  public function onOverrideChange(DomainConfigOverrideCrudEvent $event) {
    $this->configCacheTag->onSave(
      new ConfigCrudEvent($event->getOverride())
    );
  }

  public static function getSubscribedEvents(): array {
    $events[DomainConfigOverrideEvents::SAVE_OVERRIDE][] = ['onOverrideChange'];
    $events[DomainConfigOverrideEvents::DELETE_OVERRIDE][] = ['onOverrideChange'];
    return $events;
  }

}

Modified: domain_config/domain_config.services.yml — registers the new subscriber with core's system.config_cache_tag service injected.

Modified: domain_config_ui/tests/src/Functional/DomainConfigUIOverrideTest.php — cleaned up and documented testOverrides() with a regression assertion that verifies the front page change takes effect immediately without a manual cache rebuild.

Personal Note: it looks like simply firing ConfigEvents::SAVE could have some undesired side effects.