## Problem/Motivation In [#3590399](https://git.drupalcode.org/project/eca/-/work_items/3590399) it was decided that ECA does not attach cache metadata to action access results, and `->cachePerPermissions()` was removed from `ApplyRecipe::access()`. That decision is right about the codebase as a whole, but it is not currently applied consistently. A survey of all 83 `access()` implementations in the module found that bare `AccessResult` objects are the overwhelming norm - `ActionBase::access()`, the base every ECA action inherits, attaches nothing - while `eca_config` does the opposite, and has done so for years. ## Current state **Action plugins that attach cache metadata:** | Location | Introduced | |---|---| | `modules/config/src/Plugin/Action/ConfigActionBase.php:48,50` | `1bee04a5`, 2022-04-05, #3272994 | | `modules/config/src/Plugin/Action/ConfigAction.php:80` | `c1c44bf5`, 2025-10-08, #3550763 | | `modules/config/src/Plugin/Action/ConfigWrite.php:56` | inherits it indirectly | A line-blame on `ConfigAction.php:80` points at `0a6dce1f` (#3590391) rather than `c1c44bf5`, because that commit changed the false branch and kept the `cachePerPermissions()` call. `ConfigAction::access()` is structurally the same method as the one changed in #3590399 - same permission, same forbidden-with-reason-else-allowed shape, same `$return_as_object ? ... : $result->isAllowed()` tail. **The pattern is already inconsistent within `eca_config` itself.** `ConfigWrite::access()` calls `parent::access($object, $account, TRUE)`, so it inherits the cache context on the allowed path, then discards it in the YAML-invalid branch by building a fresh `AccessResult::forbidden()`. **Not action plugins, listed so the audit does not trip over them:** - `modules/endpoint/src/Controller/EndpointController.php:262-268` - a controller access callback returning `AccessResult::allowed()->addCacheContexts(['url.path', 'url.query_args', 'user', 'user.permissions'])`. A controller access callback is genuinely a different animal from an action plugin's `access()`, and its result really does end up in the render/page cache. It may well be correct as it stands. - `modules/render/src/Plugin/Action/RenderElementActionBase.php:77-83` - adds the same four contexts, but in `execute()`, not `access()`. Its `access()` at line 25 is clean. - `modules/access/src/Hook/AccessHooks.php:50,84,120` - `addCacheableDependency()` plus `mergeCacheMaxAge(0)`, but these are `hook_entity_access` / `hook_entity_field_access` / `hook_entity_create_access` implementations, not plugin `access()`. ## Proposed resolution 1. Confirm the intended rule and write it down somewhere discoverable, so the next `access()` implementation does not have to guess. The rule as decided in #3590399 is that an action plugin's `access()` returns a bare `AccessResult` with no cache metadata. 2. Decide explicitly whether that rule extends to non-action access callbacks such as `EndpointController`, or whether those are deliberately exempt because their results genuinely feed a cache. 3. Bring `eca_config` into line - `ConfigActionBase`, `ConfigAction` and, by extension, `ConfigWrite`. 4. Re-run the survey afterwards so the result is a verified state rather than a spot fix, covering `cachePerPermissions`, `cachePerUser`, `cachePerRole`, `addCacheContexts`, `addCacheTags`, `addCacheableDependency` and `setCacheMaxAge` across every `access()` implementation in the module. ## Note on the direction This issue deliberately does not assume the answer is "remove it everywhere". The opposite conclusion - that `eca_config` was right and the norm should move the other way - is a legitimate outcome, in which case #3590399 would want revisiting. The point is that three call sites currently contradict a decision that has just been made, and that should be resolved on purpose rather than left to drift. Whatever is decided, a caller relying on the cache contexts that `ConfigActionBase` currently returns would be affected, so the change wants a release note. ## Origin Found while applying the #3590399 decision, and deliberately kept out of that MR to avoid widening a targeted fix into a module-wide refactor.