Upgrading from 2.x to 3.x crashes when domain_config is not enabled

Problem

In 2.x, domain_theme_switch.info.yml declared only domain:domain as a dependency. The 3.x rewrite (#3551634) and the follow-up service fix (#3588538) introduced a hard dependency on the domain_config module, now declared in info.yml:

dependencies:
  - domain:domain
  - domain:domain_config

For sites upgrading from 2.x to 3.x, domain_config is typically not enabled, and the new code path uses domain.config_factory_override (provided by domain_config) directly — both in the configuration form and in domain_theme_switch_update_10001().

What actually happens on upgrade

composer update only changes files on disk; it does not touch the database. core.extension still lists domain_theme_switch as enabled, and Drupal is lenient about already-enabled modules whose info.yml deps become unmet: ModuleHandler::loadAll() still loads them (you only see a warning on the modules report).

So the site keeps booting after the composer update. The crash only happens when code touches the missing service:

• An admin visits /admin/config/domain/themes → ServiceNotFoundException on domain.config_factory_override.
• The site builder runs drush updb → update_10001 requests the same service and dies.

Steps to reproduce

1. Install Domain 2.x and Domain Theme Switch 2.x; configure a per-domain theme.
2. Upgrade Domain to 3.x and Domain Theme Switch to 3.x via Composer, without manually enabling domain_config.
3. Run drush updb (or visit /update.php).

Result: ServiceNotFoundException from update_10001 aborts the database update.

Proposed resolution

Keep the domain_config entry in info.yml — it is a real runtime dependency and removing it would lie to Composer, static analysis and fresh installs. Instead, add hook_requirements('update') in domain_theme_switch.install to gate the update flow with a clear, actionable message.

This relies on the standard ordering used by drush updb / update.php:

1. Bootstrap Drupal (succeeds — already-enabled modules with unmet info.yml deps still load).
2. Invoke hook_requirements('update') on every enabled module. Any REQUIREMENT_ERROR aborts before any hook_update_N runs.
3. Run pending hook_update_N hooks.
4. Run hook_post_update_N hooks.

So the gate fires before update_10001 ever touches domain.config_factory_override:

function domain_theme_switch_requirements($phase): array {
  $requirements = [];
  if ($phase === 'update' && !Drupal::moduleHandler()->moduleExists('domain_config')) {
    $requirements['domain_theme_switch_domain_config'] = [
      'title' => t('Domain Theme Switch'),
      'description' => t('Domain Theme Switch 3.x requires the Domain Configuration module. Enable it (drush en domain_config) before running database updates.'),
      'severity' => REQUIREMENT_ERROR,
    ];
  }
  return $requirements;
}

Recovery for upgrading users becomes:

composer update drupal/domain drupal/domain_theme_switch
drush updb           # blocked with a clear, actionable message
drush en domain_config
drush updb           # passes requirements; update_10001 migrates the config

Caveat

The update-phase gate does not prevent an admin who visits /admin/config/domain/themes between composer update and drush updb from hitting the same ServiceNotFoundException on the form. Adding a hook_requirements('runtime') with REQUIREMENT_WARNING would at least surface the issue on the status report, though it cannot actually block the form. In practice the update-time gate is what users hit first, since the standard upgrade workflow is composer update → drush updb.

A short note should also be added to the README and the 3.0.x release notes pointing out the new requirement.

Related issues

• #3551634 — Create new 3.x version compatible with Domain 3.x
• #3588538 — ServiceNotFoundException: domain_config_ui.manager (where the dependency was added)