Installing the Horizon Aid site template with drush site:install on plain Drupal CMS fails with "You have requested a synthetic service (kernel)"

Problem/Motivation

On a plain Drupal CMS codebase (no Varbase base, no vardot/varbase-patches, no curated core patches), installing the Horizon Aid site template directly from its recipe fails at the very end of the recipe apply:

In ContainerBuilder.php line 1104:
  You have requested a synthetic service ("kernel"). The DIC does not know how to construct this service.

Everything up to that point succeeds — every sub-recipe, the theme, the config, the content. The failure is in the RecipeAppliedEvent dispatch, so the install exits non-zero and leaves a half-configured site.

Root cause (traced, not guessed)

Drupal\canvas\EventSubscriber\RecipeSubscriber also listens on RecipeAppliedEvent. It calls PageVariantMigration::migrateDefaultTheme(), which reaches PageVariantMigration::createFromPageRegions(). That method does:

if (!\Drupal::moduleHandler()->moduleExists('canvas_page_template_component')) {
  \Drupal::service(ModuleInstallerInterface::class)->install(['canvas_page_template_component']);
}

Installing a module rebuilds the service container. The listeners that have not run yet were resolved from the OLD container, so the next listener that touches a plugin manager resolves an OOP hook class through a ClassResolver still holding the pre-rebuild container. That container has kernel registered as synthetic but never set(), hence the fatal.

The listener that trips over it is Drupal CMS's own Drupal\drupal_cms_helper\EventSubscriber\RecipeSubscriber::onApply() — verified twice, at both of the things it does:

• $config->set('page.front', ...)->save() → TypedConfigManager::hasConfigSchema() → alterDefinitions() → instantiating Drupal\ckeditor5\Hook\Ckeditor5Hooks;
• and, with that line removed, $this->entityTypeManager->getStorage('user')->resetCache([1]) → EntityTypeManager::alterDefinitions() → instantiating Drupal\menu_link_content\Hook\MenuLinkContentHooks.

Instrumented proof: at the failure the ClassResolver's container is object #52294 with has('kernel') = true, initialized('kernel') = false, while \Drupal::getContainer() is a different object #120526 with initialized('kernel') = true.

Horizon Aid triggers this because it ships canvas.page_region.vartheme_bs5_horizonaid.header and .footer, so the theme has page regions and no page variant yet. Drupal CMS's own site template byte does not ship page regions and installs green on the identical codebase — that was the control test.

Environment

• Drupal core 11.4.6
• drupal/cms
• drupal/canvas 1.11.0
• PHP 8.4
• DDEV, MariaDB 11.8
• No patches of any kind applied

Steps to reproduce

mkdir -p ~/my-drupal-cms-horizonaid && cd ~/my-drupal-cms-horizonaid
ddev config --project-type=drupal11 --docroot=web
ddev start
ddev composer create-project drupal/cms
ddev composer config minimum-stability dev
ddev composer require drupal/horizonaid:1.0.x-dev
ddev drush si -y ../recipes/horizonaid

Expected: the site installs. Actual: exits 1 with the synthetic-kernel RuntimeException.

Control: ddev drush si -y ../recipes/byte on the same codebase exits 0.

Proposed resolution

Add canvas_page_template_component to the recipe's install: list, so the module already exists when Canvas's RecipeAppliedEvent subscriber runs and nothing is installed mid-dispatch. One line plus an explanatory comment in recipe.yml:

install:
- vartheme_bs5_horizonaid
- better_exposed_filters
- canvas_page_template_component

Verified: with only that change, the same command exits 0 on the same codebase. The site then serves: front page 200 rendering the Canvas "Home" page, /about /resources /programs /countries /events /donate /impact /terms-and-conditions all 200, /user/login 200, /search 200 and returning results after indexing, 70 nodes, 8 canvas pages, 74 media, 25 taxonomy terms, 24 menu links, default theme vartheme_bs5_horizonaid, and zero PHP errors in the watchdog log. Verified in a real browser with zero console errors.

Note the underlying defect is upstream — a module installed during RecipeAppliedEvent leaves earlier-resolved listeners on a stale container. This issue only makes Horizon Aid stop triggering it. Worth a follow-up against drupal/canvas.

AI-Generated: Yes — the diagnosis and this summary were produced with Claude Code (Claude Opus 5) assistance. The reproduction, the control test and the fix were verified locally by a human-run install.

Remaining tasks

• ✅ File an issue
• ❌ Addition/Change/Update/Fix
• ❌ Testing to ensure no regression
• ➖ Automated unit/functional testing coverage
• ➖ Developer Documentation support
• ➖ User Guide Documentation support
• ➖ UX/UI designer responsibilities
• ➖ Accessibility and Readability
• ❌ Reviewed by a human
• ❌ Code review by maintainers
• ❌ Full testing and approval
• ❌ Credit contributors
• ❌ Review with the product owner
• ❌ Update Release Notes
• ❌ Release

User interface changes

• N/A

API changes

• N/A

Data model changes

• The canvas_page_template_component module is now installed by the recipe rather than being installed implicitly, mid-dispatch, by Canvas.

Release notes snippet

• Fixed installing the Horizon Aid site template with drush site:install on a plain Drupal CMS base, which failed with "You have requested a synthetic service (kernel)".