## Summary `\Drupal\default_content_tools\EventSubscriber\RecipeTrackerCatchup::onRecipeApplied()` resolves a logged recipe's filesystem path via: ```php $path = InstalledVersions::getInstallPath($package_name); ``` `$package_name` comes from `recipe_tracker`'s `Log::package_name` field, which `recipe_tracker` populates straight from the recipe's own `composer.json` `name` key whenever one exists at `$recipe->path . '/composer.json'` — regardless of whether that package was ever actually pulled in via `composer require`. A recipe consumed directly from a local folder (not as a Composer dependency at all — e.g. a project that keeps `recipes/` as plain, hand-maintained/vendored directories rather than requiring each recipe as its own package) can still ship a `composer.json` naming its eventual real package (e.g. `drupal/commerce_recipe_core`). `recipe_tracker` logs that name faithfully. But `Composer\InstalledVersions::getInstallPath()` throws `\OutOfBoundsException` for any package name it doesn't recognize from the *current* Composer install — it does not return `null` for "not installed", it throws. The result: the very first time `RecipeTrackerCatchup::onRecipeApplied()` iterates the `recipe_tracker_log` table and encounters *any* logged recipe like this, the exception is unhandled and the whole `RecipeAppliedEvent` listener chain breaks — for every subsequently-applied recipe in the same install, not just the one whose content deletion was actually requested via `delete_recipes`. ## Steps to reproduce 1. A site's `recipes/` directory contains at least one recipe consumed as a plain local folder, not via `composer require`, but which still ships its own `composer.json` (common for a recipe that is *also* published to Packagist/drupal.org, just not currently required as a dependency in this particular site). 2. Install `recipe_tracker` (so `RecipeAppliedEvent` gets logged with that recipe's `package_name`) and `default_content_tools`. 3. Mark *any* recipe for deletion via `markRecipeContentForDeletion` (does not need to be the local-folder recipe from step 1 — any entry in `delete_recipes` triggers the sweep). 4. Apply a recipe (any recipe) so `RecipeAppliedEvent` fires again and `RecipeTrackerCatchup::onRecipeApplied()` runs. 5. `\OutOfBoundsException: Package "drupal/commerce_recipe_core" is not installed` is thrown from `InstalledVersions::getInstallPath()`, uncaught. ## Suggested fix Two related issues, ideally both addressed: 1. **Immediate robustness**: wrap the `InstalledVersions::getInstallPath($package_name)` call in a try/catch for `\OutOfBoundsException`, matching the defensive style already used elsewhere in this module (`\Drupal\default_content_tools\DefaultContentDelete::deleteContent()` wraps its own per-entity work in try/catch; `recipe_tracker`'s own `RecipeTrackerSubscriber` already wraps its `composer.json` read in try/catch for exactly this "might not actually resolve" reason). A single unresolvable logged recipe should not break the sweep for every other logged recipe. 2. **Root cause**: going through `Composer\InstalledVersions` at all is the wrong resolution strategy for a recipe that isn't actually a Composer dependency of the current project — which is a legitimate, supported way to consume a recipe (local/unwrapped, no `composer require` involved). Since the recipe's own `composer.json` is what `recipe_tracker` already read to get `package_name` in the first place, and that `composer.json` still exists on disk at the recipe's own path, a more robust resolution would use Drupal core's own recipe discovery (the same mechanism `drush recipe:apply <name>` and Composer's `drupal-recipe` installer type use to locate recipes on disk) to find a recipe whose own `composer.json` `name` matches the logged `package_name`, rather than asking Composer's runtime install metadata to resolve a package that may never have been a tracked Composer dependency at all. Happy to open an MR for the try/catch fix (item 1) if that's welcome — will follow up separately on a root-cause fix (item 2) since it needs more design discussion (recipe discovery service, matching by composer.json name vs. Composer runtime).