> :robot: _This was written by an AI agent on behalf of @lussoluca._ ## Problem Several wrappers cannot delegate to the service they replace, because the profiler has to observe something in the middle of a core method. Those places copy core code instead of calling it. A copy does not fail when core changes, it keeps running the old logic, so the drift is only found by reading both files side by side. An audit of every such copy on Drupal 11.4.5 found two that have already drifted, and no test that would have caught either. ### The state cache is never written `StateWrapper` at `src/State/StateWrapper.php:46` and `:55` delegates `get()` and `getMultiple()` to the decorated service, but inherits `set()`, `setMultiple()`, `delete()`, `deleteMultiple()` and `resetCache()` from `Drupal\Core\State\State`. Reads therefore run on the decorated instance while writes run on the wrapper's own inherited one, and both are a `CacheCollector` bound to the same `state` cache ID. Only one of them is ever destructed, and it is the wrong one. Core tags `state` with `needs_destruction` in `core/core.services.yml`, `RegisterServicesForDestructionPass` reads that tag before the decoration is resolved, and `DrupalKernel.php:726` then destructs whatever `state` resolves to, which is the wrapper. The decorated instance is the one that accumulates keys, because `State::resolveCacheMiss()` calls `persist()` on every read, and its `destruct()` is never called. Measured on a standard install with 12 rows in the `state` key value collection: ```text after 2 reads: wrapper keysToPersist=0 storage=0 | inner keysToPersist=4 storage=4 state cache entry: present, keys=0 ``` Every state key is resolved against the key value store on every request, on every site with webprofiler enabled. The empty cache entry is not corrupt, only useless: `CacheCollector::updateCache()` returns early when there is nothing to persist, so the wrapper's destruct writes nothing rather than overwriting good data. ### The config entity storage decorator delegates to methods core removed `ConfigEntityStorageDecorator` at `src/Entity/ConfigEntityStorageDecorator.php:74` and `:81` declares `loadRevision()` and `deleteRevision()`. Neither method exists on any interface the class implements, nor on `ConfigEntityStorage` or `EntityStorageBase`. They moved to `RevisionableStorageInterface`, and config entity storage never had them. Calling either one fatals. The class is a hand written list of one delegating method per interface method, so it drifts in both directions: core adding a method leaves a decorator that no longer satisfies the interface, and core removing one leaves a method that fatals. ### Nothing guards the remaining copies Four core method bodies are copied verbatim and currently match core, which means they are correct today and silently wrong after any core change: - **`AccessManagerWrapper::performCheck()`** copies `Drupal\Core\Access\AccessManager::performCheck()`. - **`TranslationManagerWrapper::doTranslate()`** copies `Drupal\Core\StringTranslation\TranslationManager::doTranslate()`. - **`ThemeNegotiatorWrapper::determineActiveTheme()`** copies `Drupal\Core\Theme\ThemeNegotiator::determineActiveTheme()`. - **`Twig\ComponentNodeVisitor::getComponent()`** copies `Drupal\Core\Template\ComponentNodeVisitor::getComponent()`, including the component ID regular expression. Three service definitions in `webprofiler.services.yml` repeat a core argument list verbatim, because the decorator subclasses the service it decorates and has to construct the parent as well as hold the inner service: - **`webprofiler.debug.entity_type.manager`** at line 106 repeats the seven arguments of `entity_type.manager`. - **`webprofiler.debug.state`** at line 161 repeats the three arguments of `state`. - **`webprofiler.debug.mail_manager`** at line 168 repeats the seven arguments of `plugin.manager.mail`. All three match core 11.4.5 today. Core adding, removing or reordering an argument breaks the container build. ## Proposed resolution **Make `StateWrapper` a real decorator.** Delegate every `StateInterface` method to the decorated service, and delegate `destruct()` to it as well so the keys collected while reading reach the cache entry. The class still has to extend `State` because the decorated service is typed as the concrete class, but nothing then uses the inherited machinery, and one `CacheCollector` owns the cache ID instead of two. Adding the `needs_destruction` tag to the decorator is not the fix: the tag already resolves to the wrapper, and re-declaring it would only destruct the decorated service twice. **Delete `loadRevision()` and `deleteRevision()`** from `ConfigEntityStorageDecorator`. **Add a test that fails when core moves.** For the four copied method bodies, record a hash of the normalized core source, so a core change fails the test and names the copy to review. For the decorator, assert its declared methods are exactly the methods of the interfaces it implements, which catches drift in both directions. For the three service definitions, parse both YAML files and assert core's argument list still appears in the decorator's, in order. ## Verification On Drupal 11.4.5, PHP 8.5, on a standard install with webprofiler enabled. State cache, after the change, reading three keys and then destructing the `state` service: | Check | Before | After | | --- | --- | --- | | Keys pending on the decorated service after reads | 4 | 3 | | Keys pending after `destruct()` | 4 | 0 | | Keys in the `state` cache entry | 0 | 5 | Write delegation round trips through the decorated service: `set()` and `get()`, `setMultiple()` and `getMultiple()`, and `deleteMultiple()` all return the expected values, and the probe keys leave no rows behind. Three page requests return HTTP 200. Decorator surface after the deletion: 25 interface methods, 25 declaring methods. The new test passes against core 11.4.5, and a negative control confirms the service argument assertion fails when a core argument is added. ## Out of scope The module also carries copies of Symfony code, from `web-profiler-bundle`, `twig-bridge`, `monolog-bridge`, `framework-bundle` and `error-handler`. Four of those packages are not installed, so there is no local copy to compare against and nothing flags them as stale. Two of the `templates/Error` files are still byte identical to `symfony/error-handler` v7.4.15 while the assets next to them have diverged. That is a separate audit and a separate issue.