## Problem/Motivation `DependencyCalculation::addDependenciesFromFields()` calls core's `EntityType::getBundleConfigDependency()` without first checking that the bundle exists. That core method does **not** return a falsy value for a missing bundle — it throws: ``` LogicException: Missing bundle entity, entity type storage_type, entity id sp_slack. ``` `src/Service/DependencyCalculation.php` line 203: ```php if (isset($bundle) && $bundle !== ContentEntityTypes::ALL && ($bundle_dependency = $this->entityTypeManager->getDefinition($entity_type_id)->getBundleConfigDependency($bundle))) { if (in_array('bundle', self::$enabledCalculations, TRUE)) { ``` The `&& (...)` idiom implies the call may return something empty, but `EntityType::getBundleConfigDependency()` (`core/lib/Drupal/Core/Entity/EntityType.php` lines 958-979) throws a `LogicException` instead. Because `calculateDependencies()` runs from `Eca::preSave()`, this makes saving an ECA config entity **hard-fail** whenever it references a bundle that does not exist *yet*. That is a completely normal situation during a recipe apply or a config import, where install order is decided by `ConfigDependencyManager::sortAll()` — which sorts by dependency-graph weight and tie-breaks alphabetically. An `eca.eca.*` config therefore sorts *before* the bundle config entity it refers to whenever both are weight-0 leaves. Two further defects on the same lines: 1. **Inverted guard order.** The `in_array('bundle', self::$enabledCalculations, TRUE)` check sits on line 204, *inside* the `if` whose condition already invoked `getBundleConfigDependency()` on line 203. So the throwing call happens even when bundle dependency calculation is disabled in `eca.settings`, which means the setting cannot be used to avoid the crash. 2. **`$bundle` leaks across loop iterations.** `$matches` is explicitly `unset()` at line 216, but `$bundle` is never reset at the top of the `foreach` at line 174. Once any `*type*` key sets `$bundle`, a later config key in the same plugin whose value resolves to an entity type reuses the stale `$bundle`, producing a bundle dependency for the wrong entity type. This code path became much more reachable after #3585741 fixed the reversed `mb_strpos()` arguments on line 182, so the previously near-dead branch is now exercised broadly. The existing unit coverage (`tests/src/Unit/DependencyCalculationTest.php` lines 113 and 179) *mocks* `getBundleConfigDependency()`, so the throwing path is untested by construction. ## Steps to reproduce 1. Install `eca`, `eca_content` and `storage` (Storage Entities). 2. Save an ECA config entity whose action/event configuration contains a `type` key pointing at an entity type + bundle that does not exist, e.g. `type: 'storage sp_slack'`. ```php $eca = \Drupal::entityTypeManager()->getStorage('eca')->create([ 'id' => 'test_dep_calc', 'events' => ['e1' => [ 'plugin' => 'content_entity:update', 'label' => 'x', 'configuration' => ['type' => 'storage sp_nonexistent'], 'successors' => [], ]], 'conditions' => [], 'actions' => [], 'gateways' => [], ]); \Drupal::service('eca.service.dependency_calculation')->calculateDependencies($eca); // LogicException: Missing bundle entity, entity type storage_type, entity id sp_nonexistent. ``` Real-world reproducer: a recipe that ships both `storage.storage_type.sp_slack` and an `eca.eca.*` model referencing `type: 'storage sp_slack'`. `drush recipe` fails, because `eca.eca.*` sorts alphabetically before `storage.storage_type.*` when both are weight-0 leaves. Note how badly this presents to the user: core's `RecipeCommand::execute()` catches the real error, attempts a checkpoint rollback, and only catches `ConfigImporterException` from that rollback — so any other exception raised during rollback replaces and *hides* this `LogicException` entirely. ## Proposed resolution Derive the bundle dependency name without loading the bundle config entity. For a config-provided bundle the dependency name is fully deterministic from the bundle entity type definition (`ConfigEntityType::getConfigPrefix() . '.' . $bundle`), so loading the entity is unnecessary and the result is byte-identical to what core produces. Concretely: 1. Add a protected helper `getBundleDependency(string $entity_type_id, string $bundle): ?array` that returns `['type' => 'config', 'name' => $prefix . '.' . $bundle]` for config bundle entity types, falls back to loading the bundle entity for non-config bundle entity types (returning `NULL` when absent rather than throwing), and delegates to `getBundleConfigDependency()` when the entity type has no bundle entity type at all (that branch cannot throw). 2. Move the `in_array('bundle', self::$enabledCalculations, TRUE)` check *outward* so it gates the whole block before any resolution happens. 3. Reset `$bundle = NULL;` at the top of the `foreach` and compare with `$bundle !== NULL` instead of `isset($bundle)`. Deriving rather than skipping matters: there is no hook that re-saves ECA config entities when a *bundle* is later created. `ContentHooks::entityBundleCreate()` (`modules/content/src/Hook/ContentHooks.php` lines 61-64) only dispatches an ECA event; only `fieldConfigInsert()` (line 302) adds dependencies afterwards, and only for `field.field.*`. So simply skipping a missing bundle would silently leave the dependency absent forever. ## Remaining tasks - [ ] Apply the three-part fix. - [ ] Add unit coverage for the missing-bundle case (stop mocking `getBundleConfigDependency()` wholesale; stub the bundle entity type and its config prefix instead). - [ ] Correct the misleading comment at lines 243-245, which implies bundle-create re-save handling that does not exist. ## User interface changes None. ## API changes None. One new protected method on `DependencyCalculation`. ## Data model changes None. AI-Generated: Yes (Used OpenCode with Claude to diagnose the failure from a `drush recipe` stack trace, locate the root cause, and draft the fix and test.)