## Problem / Motivation Installing a recipe from the command line on a Drupal CMS codebase built with `minimum-stability: dev` fails with: ``` In ContainerBuilder.php line 1104: You have requested a synthetic service ("kernel"). The DIC does not know how to construct this service. ``` The failure is in the recipe-apply batch, after `install_recipe_required_modules`. Verified stack trace (abridged, from `drush si -vvv`): ``` Drupal\Core\Config\Config->save() (drupal_cms_helper RecipeSubscriber.php:43) Drupal\Core\Config\TypedConfigManager->hasConfigSchema() Drupal\Core\Config\TypedConfigManager->getDefinition() Drupal\canvas\CoreBugFix\TypedConfigManagerWithCachePollutionFix->getDefinitionWithReplacements() Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() Drupal\Core\Config\TypedConfigManager->alterDefinitions() Drupal\Core\Extension\ModuleHandler->alter() (hook_config_schema_info_alter) Drupal\Core\Extension\ModuleHandler->getHookImplementationList() Drupal\Core\Utility\CallableResolver->getCallableFromDefinition() Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() ContainerBuilder->get() -> synthetic service "kernel" ``` The class that cannot be constructed was identified precisely, by instrumenting `ClassResolver::getInstanceFromDefinition()` to log the definition on failure: ``` FAILED Drupal\ckeditor5\Hook\Ckeditor5Hooks :: You have requested a synthetic service ("kernel"). ``` `Drupal\ckeditor5\Hook\Ckeditor5Hooks` implements `hook_config_schema_info_alter()`, so core must construct it to build the listener list. It does not inject `kernel` directly, but one of its constructor dependencies resolves to the **synthetic** `kernel` service, which by definition cannot be constructed while the container is still a `ContainerBuilder` -- which is the case during a CLI install. ### Relationship to #3591441 This looks like the same defect that Gábor Hojtsy diagnosed and fixed in #3591441, *Installing a site template fails with a "synthetic service (kernel)" error in dev checkouts*, but in a different subscriber and on a different path: drush on the command line against released Drupal CMS 2.1.4, rather than the browser installer on a dev checkout. That issue's cause, quoting its summary, was that `Drupal\CMS\ThemeDevelopmentSubscriber` held its services by constructor injection, so after applying a recipe rebuilt the container the subscriber was still using services belonging to a container that had since been replaced -- and Canvas's `TypedConfigManager` decorator is what turns a cheap `getDefinition()` into a full `getDefinitions()` with hook alters, surfacing the stale container. `Drupal\drupal_cms_helper\EventSubscriber\RecipeSubscriber` (drupal_cms_helper 2.1.4) still has exactly that shape: ```php final readonly class RecipeSubscriber implements EventSubscriberInterface { public function __construct( private ConfigFactoryInterface $configFactory, private AliasManagerInterface $aliasManager, private EntityTypeManagerInterface $entityTypeManager, ) {} ``` and `RecipeSubscriber.php:43` -- the `$config->set('page.front', $front_system_path)->save()` in `onApply()` -- is the top frame of the trace above. ## Steps to reproduce ``` mkdir -p my-drupal-cms-test && cd my-drupal-cms-test ddev config --project-type=drupal11 --docroot=web ddev composer create-project drupal/cms ddev composer config minimum-stability dev ddev drush si -y ../recipes/drupal_cms_starter ``` Environment: Drupal CMS 2.1.4, Drupal core 11.4.6, PHP 8.4, `drupal/canvas` 1.11.0, drush 13.7.7 (also reproduced on 13.8.0). ## Evidence that it is not recipe-specific - Reproduced with the stock **`drupal_cms_starter`** recipe, with no contrib site template involved. - Reproduced with the **`varbase_starter`** site-template recipe. - Not caused by any one config action: removing the site template's `system.site: page.front` action -- which is what makes `drupal_cms_helper`'s `RecipeSubscriber` call `Config::save()` -- only moves the failure earlier in the recipe batch; it still dies on the same synthetic-service error. - Not a drush version issue: reproduced on drush 13.7.7 and 13.8.0. ## Proposed resolution I have not implemented any of these and I am not proposing a merge request; these are for the maintainers to weigh. 1. Apply the same fix as #3591441 to `RecipeSubscriber`: resolve `config.factory`, `path_alias.manager` and `entity_type.manager` from whichever container is live at call time instead of injecting them. If that is the right shape, it may be worth auditing every event subscriber that can run across a recipe-triggered container rebuild rather than fixing them one at a time. 2. Have `Ckeditor5Hooks` (or whichever dependency pulls in `kernel`) resolve the kernel lazily rather than through constructor injection, so the hook class can be constructed before the container is compiled. 3. Avoid resolving the full `hook_config_schema_info_alter` listener list during a config save while the installer's `ContainerBuilder` is still active. 4. Make `ClassResolver` / `ModuleHandler` degrade gracefully when a hook class cannot be constructed during install, rather than fataling the whole install. Options 2 to 4 are core-side, so if the maintainers judge the defect to be core's rather than Drupal CMS's, I am happy to move this report to the core queue. ## Remaining tasks - [x] Reproduce on a clean build - [x] Identify the failing hook class - [x] Confirm it is not recipe-specific or drush-version-specific - [ ] Maintainer decision on which of the proposed resolutions to take - [ ] Fix - [ ] Test coverage for a CLI recipe install after a container rebuild - [ ] Code review by maintainers ## User interface changes None proposed by this report. ## API changes None proposed by this report. ## Data model changes None proposed by this report. ## Release notes snippet N/A --- AI-Generated: Yes