From c5370d4b3712db4fb6b5404d5d1de6bbe8b525eb Mon Sep 17 00:00:00 2001 From: Stanislav Zhuk Date: Wed, 4 Nov 2026 10:08:11 +0200 Subject: [PATCH] fix(drupal-contrib): rebuild caches before enabling the module, fixes #153 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## Short Summary (TL;DR) Contrib setup now runs `drush cr` between `drush si` and `drush en`, which stops the intermittent "no commands defined in the pm namespace" failures. ## The Issue - Fixes #153 The daily contrib CI jobs often fail on the first attempt and pass on rerun. Example: https://github.com/ddev/coder-ddev/actions/runs/41777312122/job/126400559017 ``` ✓ Drupal installed (6s) Enabling pathauto (module)... There are no commands defined in the "pm" namespace. Failed to run drush en pathauto -y: exit status 1 ✗ pathauto not found in enabled modules — enable failed ``` The `ddev-web` healthcheck requests the site every 10s. If a request lands during `drush si`, Drupal caches a container from a half-installed site. The next `drush en` boots from it, and Drush fails to autowire `PmCommands`: ``` [debug] Could not instantiate Drush\Commands\pm\PmCommands: Cannot autowire service "Drupal\user\PermissionHandlerInterface" ``` Drush logs this only with `--debug`. The same stale cache can also fail with `Call to undefined function Drupal\update\Hook\update_storage_clear()`. ## How This PR Solves The Issue `drush cr` after `drush si` rebuilds the container from the installed site. `drupal-core` already does this. `test-issue-branches.sh` gets the same fix. ## Manual Testing Instructions In a pathauto checkout with `ddev-drupal-contrib`, request the site in a loop: ```bash while true; do curl -s -o /dev/null "$(ddev describe -j | jq -r .raw.httpurl)"; sleep 1; done & ddev drush si minimal -y && ddev drush en pathauto -y # Expect: fails most of the time ddev drush si minimal -y && ddev drush cr && ddev drush en pathauto -y # Expect: succeeds kill %1 ``` ## Automated Testing Overview Claude Code ran the loop above locally (Drush 13.8, Drupal 11.4): without `drush cr`, 15/15 runs failed; with it, 15/15 passed. CI contrib jobs confirm the template change. 🤖 Developed with assistance from [Claude Code](https://claude.ai/code) Co-Authored-By: Claude Opus 5.5 --- drupal-contrib/scripts/test-issue-branches.sh | 3 +++ drupal-contrib/template.tf | 4 ++++ 2 files changed, 7 insertions(+) diff --git a/drupal-contrib/scripts/test-issue-branches.sh b/drupal-contrib/scripts/test-issue-branches.sh index 56c56c1..2fb2b19 100755 --- a/drupal-contrib/scripts/test-issue-branches.sh +++ b/drupal-contrib/scripts/test-issue-branches.sh @@ -155,6 +155,9 @@ for SPEC in "${TESTS[@]}"; do continue fi + # A web request during `drush si` can cache a half-installed container. + ddev drush cr 2>&1 | tail -2 + log "Enabling $PROJECT..." if ! ddev drush en "$PROJECT" -y 2>&1; then log "WARNING: could not enable $PROJECT (may need manual enable)" diff --git a/drupal-contrib/template.tf b/drupal-contrib/template.tf index 0b7948e..bcdfc8e 100644 --- a/drupal-contrib/template.tf +++ b/drupal-contrib/template.tf @@ -873,6 +873,10 @@ COMPOSE_EOF fi if [ "$SETUP_FAILED" = "false" ]; then + # A healthcheck request during `drush si` can cache a half-installed + # container, which breaks the next `drush en`. + ddev drush cr >> "$SETUP_LOG" 2>&1 || true + # Enable the module or theme. # ddev drush en can exit non-zero even when the module ends up enabled # (e.g. a post-install hook in another module throws a fatal), so verify