## AI disclosure AI-Generated: Yes (agent traced the code in 2.1.x and 3.1.x, ran the reproduction on a fresh site and drafted this issue; reviewed and edited by jurgenhaas). <details> <summary>LLM-summary - Click to expand</summary> ### Full analysis #### 1. How the subscription index is built and used ECA keeps a derived index of "event name => enabled models" in the State key `eca.subscribed`. Three runtime consumers trust it: | Consumer | 3.1.x (bd2d753d, = 3.1.10) | 2.1.x (a9ff0e02, same lines as 2.1.24) | |---|---|---| | `DynamicSubscriber::getSubscribedEvents()` reads the state on every request, because `EcaServiceProvider` adds the subscriber through `addMethodCall('addSubscriber')` when the dispatcher is instantiated | [DynamicSubscriber.php#L80](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/EventSubscriber/DynamicSubscriber.php#L80), [#L93](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/EventSubscriber/DynamicSubscriber.php#L93), [EcaServiceProvider.php#L22](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/EcaServiceProvider.php#L22) | [DynamicSubscriber.php#L27-L29](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/src/EventSubscriber/DynamicSubscriber.php#L27-29), [EcaServiceProvider.php#L21](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/src/EcaServiceProvider.php#L21) | | `Processor::execute()` takes the model IDs from the state and loads each one, with no `status()` check before executing it | [Processor.php#L259](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/Processor.php#L259), [#L264](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/Processor.php#L264), [#L293](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/Processor.php#L293) | [Processor.php#L146](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/src/Processor.php#L146), [#L151](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/src/Processor.php#L151), [#L178](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/src/Processor.php#L178) | The only place that filters disabled models is the rebuild itself, `EcaStorage::doRebuildSubscribedEvents()`, which skips `!$eca->status()` ([3.1.x #L164](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/Entity/EcaStorage.php#L164), [2.1.x #L164](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/src/Entity/EcaStorage.php#L164)). That matches the decision in #3244149: filter once in the storage layer, so the processor only receives relevant models. #### 2. When the index is rebuilt `EcaStorage::rebuildSubscribedEvents()` ([3.1.x #L80](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/Entity/EcaStorage.php#L80), [2.1.x #L97](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/src/Entity/EcaStorage.php#L97)) is called from exactly these places: - `EcaStorage::doPostSave()` ([3.1.x #L113](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/Entity/EcaStorage.php#L113), [2.1.x #L134](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/src/Entity/EcaStorage.php#L134)) - `EcaStorage::delete()` ([3.1.x #L123](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/Entity/EcaStorage.php#L123), [2.1.x #L144](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/src/Entity/EcaStorage.php#L144)) - `drush eca:subscriber:rebuild` ([3.1.x EcaCommands.php#L51](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/Drush/Commands/EcaCommands.php#L51), [2.1.x #L201](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/src/Drush/Commands/EcaCommands.php#L201)) - 2.1.x only: the one-off `eca_update_8009()` ([eca.install#L197](https://git.drupalcode.org/project/eca/-/blob/a9ff0e025af189d8a17d20c2bf194d0e3a0e0551/eca.install#L197)) There is no listener on `ConfigEvents`, and no `hook_rebuild()` / cache flush hook, so `drush cr` does not touch the state. The 3.1.x docblock of `DynamicSubscriber` states the assumption explicitly: entity save and delete "are the only moments at which the set of used events can change" ([#L35-L37](https://git.drupalcode.org/project/eca/-/blob/bd2d753d495399bb78b0e571215ab8d6b54672a4/src/EventSubscriber/DynamicSubscriber.php#L35-37)). #### 3. Why raw config writes bypass it Core only runs the entity lifecycle when the entity API or the config importer is used: - `Config::save()` writes storage and dispatches `ConfigEvents::SAVE`, nothing else ([11.4.11 Config.php#L201](https://git.drupalcode.org/project/drupal/-/blob/11.4.11/core/lib/Drupal/Core/Config/Config.php#L201), [#L235](https://git.drupalcode.org/project/drupal/-/blob/11.4.11/core/lib/Drupal/Core/Config/Config.php#L235)). `Config::delete()` is the same ([#L246](https://git.drupalcode.org/project/drupal/-/blob/11.4.11/core/lib/Drupal/Core/Config/Config.php#L246), [#L253](https://git.drupalcode.org/project/drupal/-/blob/11.4.11/core/lib/Drupal/Core/Config/Config.php#L253)). In 10.6 the lines are 201/232 and 243/250. - The config importer goes through the entity storage: `ConfigImporter::importInvokeOwner()` ([#L1073](https://git.drupalcode.org/project/drupal/-/blob/11.4.11/core/lib/Drupal/Core/Config/ConfigImporter.php#L1073), [#L1092-L1099](https://git.drupalcode.org/project/drupal/-/blob/11.4.11/core/lib/Drupal/Core/Config/ConfigImporter.php#L1092-1099)) calls `ConfigEntityStorage::importUpdate()` / `importDelete()`, which run `$entity->save()` / `$entity->delete()` ([ConfigEntityStorage.php#L366-L374](https://git.drupalcode.org/project/drupal/-/blob/11.4.11/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php#L366-374), [#L381-L385](https://git.drupalcode.org/project/drupal/-/blob/11.4.11/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php#L381-385)). So `drush cim` is safe. - Drush 13.8.0 `config:set` and `config:delete` use the config factory directly: `getEditable($config_name)` and `->set($key, $data)->save()` / `->delete()` (`src/Commands/config/ConfigCommands.php` lines 148, 168, 228, 237). The same holds for `\Drupal::configFactory()->getEditable('eca.eca.X')->set('status', FALSE)->save()` in custom code, update hooks or deployment scripts. A contrib example of a raw `eca.eca.*` write is `eca_tamper_post_update_fix_original_id()`. It does not touch `status` or `events`, so it is harmless here, but it shows that raw writes to `eca.eca.*` happen in practice. #### 4. Reproduction (verified) Fresh site: Drupal 11.4.11, ECA 3.1.10, Drush 13.8.0, SQLite, modules `eca eca_base eca_log config`. Model imported with `drush cim --partial` (validated with the ECA Guide validator, 0 errors / 0 warnings): ```yaml langcode: en status: true dependencies: module: - eca_base - eca_log - modeler_api third_party_settings: modeler_api: storage: none label: 'Stale subscription repro' documentation: 'Writes the logged message into the state key eca_repro.last on every error log entry.' summary: 'Writes the last error message into state.' tags: { } version: v1 id: stale_repro weight: 0 events: Event_log: plugin: 'log:log_message' label: 'Error logged' configuration: channel: repro min_severity: 3 successors: - id: Activity_write condition: '' conditions: { } gateways: { } actions: Activity_write: plugin: eca_keyvaluestore_write label: 'Remember last message' configuration: collection: state key: eca_repro.last value: '[log:message:raw]' use_yaml: false validate_yaml: false ifnotexists: false successors: { } ``` Transcript (shortened): ``` ## 1 enabled baseline $ drush php:eval "\Drupal::logger('repro')->error('one');" $ drush state:get eca_repro.last one ## 2 disable via config:set $ drush -y config:set eca.eca.stale_repro status false --input-format=yaml $ drush config:get eca.eca.stale_repro status 'eca.eca.stale_repro:status': false ## 3 entity view $ drush php:eval "var_export(\Drupal::entityTypeManager()->getStorage('eca')->load('stale_repro')->status());" false ## 4 subscription state $ drush state:get eca.subscribed --format=json {"eca.subscribed":{"eca_log.message":[{"stale_repro":{"Event_log":"repro::3"}}]}} ## 5 after drush cr $ drush cr {"eca.subscribed":{"eca_log.message":[{"stale_repro":{"Event_log":"repro::3"}}]}} ## 6 log error while disabled $ drush php:eval "\Drupal::logger('repro')->error('two');" $ drush state:get eca_repro.last two <- the disabled model executed ## 7 rebuild $ drush eca:subscriber:rebuild {"eca.subscribed":[]} $ drush php:eval "\Drupal::logger('repro')->error('three');" $ drush state:get eca_repro.last two <- not executed any more ## 8 reverse: enable via config:set $ drush -y config:set eca.eca.stale_repro status true --input-format=yaml {"eca.subscribed":[]} $ drush php:eval "\Drupal::logger('repro')->error('four');" $ drush state:get eca_repro.last two <- enabled model never executes ## control: entity API $ drush php:eval "...->load('stale_repro')->enable()->save();" {"eca.subscribed":{"eca_log.message":[{"stale_repro":{"Event_log":"repro::3"}}]}} $ drush php:eval "...->load('stale_repro')->disable()->save();" {"eca.subscribed":[]} ``` Note: without `--input-format=yaml`, Drush passes the string `"false"`, which the boolean schema cast turns into `TRUE`. That is a separate trap, unrelated to ECA. Not reproduced, inferred from the code: `drush config:delete eca.eca.X` leaves the ID in the state. `Processor::execute()` then loads `NULL` and `continue`s, so nothing runs. The dispatcher still subscribes the event, though, until something rebuilds the index. #### 5. Real-world impact observed Eight production sites on 2.1.24 had a model disabled through raw config writes (status flipped plus the `eca.model.*` entry deleted in the same 30-minute window, no deployment involved). For three months, six of them kept executing the model on every error log entry, sending notifications to an external alerting system. The two sites that stopped had an unrelated ECA model saved in the meantime, which rebuilt the state. Regular deployments with `drush config-import` did not heal it, because active and sync config already matched (`status: false`), so the importer saved nothing. `drush eca:subscriber:rebuild` fixed all six immediately. #### 6. Proposed resolution, with reasoning 1. **Processor backstop.** In `Processor::execute()`, right after `$eca_storage->load($eca_id)`, skip the model when `!$eca->status()` (log at debug level). The entity is already loaded, so the cost is one method call. This does not reverse #3244149: the storage still filters, the processor only stops trusting a stale index. It fixes the dangerous direction (disabled but running) even when the state is stale for any other reason (manual state edits, interrupted saves, failed lock acquisition in `rebuildSubscribedEvents()`). 2. **Rebuild on raw config CRUD.** Subscribe to `ConfigEvents::SAVE`, `DELETE` and `RENAME`. For names starting with `eca.eca.`, call `rebuildSubscribedEvents()`. On SAVE, only do it when `ConfigCrudEvent::isChanged('status')` or `isChanged('events')`. Entity saves will then rebuild twice (config event first, `doPostSave()` second), but the second call ends at the `state->get() !== $subscribedEvents` comparison. Skipping while `\Drupal::isConfigSyncing()` is optional, because the importer path already rebuilds through the entity hooks. This fixes the reverse direction (enabled but never running), which a processor check cannot fix. 3. **Heal on cache rebuild.** Implement `hook_rebuild()` (a `#[Hook('rebuild')]` method in 3.1.x) that calls `rebuildSubscribedEvents()`, so that `drush cr` fixes a stale index without needing to know about the ECA command. 4. **Heal existing sites.** Add a post-update function that calls `rebuildSubscribedEvents()` once. 5. Adjust the `DynamicSubscriber` docblock (3.1.x lines 35-37 and 46-55). Rejected: dropping the State-based index in favor of loading all enabled models per event. #3381551 moved initialization into State for performance reasons, and the points above keep that. #### 7. Tests to add (kernel) - Raw `configFactory()->getEditable('eca.eca.x')->set('status', FALSE)->save()`: the model does not execute and the state no longer lists it. - Raw set to `TRUE`: the model executes. - Raw `delete()`: the state no longer lists it. - Corrupt the state manually, invoke `drupal_flush_all_caches()`: the state is rebuilt. - Corrupt the state manually with a disabled model listed: the processor skips it. This overlaps with the open #3585750 (direct tests for `Eca` and `EcaStorage`). </details> ## Problem/motivation A disabled ECA model keeps executing when `status` was changed through the config API instead of the entity API. Examples are `drush config:set`, `drush config:delete`, or `configFactory()->getEditable()` in update hooks and deployment scripts. The reverse also happens: a model enabled this way never runs. The `eca.subscribed` state is rebuilt only in `EcaStorage::doPostSave()`, `EcaStorage::delete()` and `drush eca:subscriber:rebuild`. Raw config writes skip the entity lifecycle, so the index goes stale. `drush cr` does not heal it, and neither does `drush cim` when active and sync config already match. `Processor::execute()` then loads each listed model and runs it without checking `status()`. References: 3.1.x `src/Processor.php` lines 264 and 293, `src/Entity/EcaStorage.php` lines 113, 123 and 164. 2.1.x `src/Processor.php` lines 151 and 178, `src/Entity/EcaStorage.php` lines 134, 144 and 164. Related: #3244149, #3381551, #3585750. On eight production sites running 2.1.24, a model disabled this way kept sending notifications for three months. ### Steps to reproduce Drupal 11.4.11, ECA 3.1.10, Drush 13.8.0. Enable `eca_base` and `eca_log`. Import a model with a `log:log_message` event (channel `repro`) and an `eca_keyvaluestore_write` action that writes `[log:message:raw]` to state key `eca_repro.last`. ``` drush -y config:set eca.eca.stale_repro status false --input-format=yaml drush cr drush state:get eca.subscribed # still lists stale_repro under eca_log.message drush php:eval "\Drupal::logger('repro')->error('two');" drush state:get eca_repro.last # "two": the disabled model executed ``` Expected: a disabled model never executes. `drush eca:subscriber:rebuild` restores the expected behavior. The same steps with `status true` on a disabled model leave it subscribed to nothing. ## Proposed resolution Skip models with `!$eca->status()` in `Processor::execute()` right after loading them. This is a cheap backstop, and the storage keeps filtering as agreed in #3244149. Rebuild the index on `ConfigEvents::SAVE`, `DELETE` and `RENAME` for `eca.eca.*`, on SAVE only when `status` or `events` changed. Also rebuild it in `hook_rebuild()`, so `drush cr` heals a stale state. Add a post-update function that rebuilds it once for existing sites. ## Remaining tasks - [ ] MR against 3.1.x with kernel tests for raw set, raw delete, cache rebuild and the processor backstop - [ ] Decide on a 2.1.x backport - [ ] Review ## User interface changes None. ## API changes None. A new config event subscriber and a `rebuild` hook implementation are added internally. ## Data model changes None. A post-update function rebuilds the `eca.subscribed` state once.