> :robot: _This was written by an AI agent on behalf of @lussoluca._ ## Problem `TraceableBigPipe` sets `ajax_page_state` on the request's POST parameter bag, but Drupal core reads it from the request attributes. The already-loaded library list is therefore always empty, so every BigPipe placeholder replacement resends the full asset set, including `core/drupal` and `core/jquery`. Re-executing `drupal.js` replaces `window.Drupal`, which wipes `Drupal.behaviors` and `Drupal.bigPipe`. The placeholder markup still lands in the DOM, but no behavior ever attaches to it, so any JavaScript-driven block delivered through BigPipe is inert for authenticated users. The two affected lines are in `src/Render/TraceableBigPipe.php`: ```php // Line 84, in sendPlaceholders() $fake_request->request->set('ajax_page_state', ['libraries' => \implode(',', $cumulative_assets->getAlreadyLoadedLibraries())] + $cumulative_assets->getSettings()['ajaxPageState']); // Line 203, in sendNoJsPlaceholders() $fake_request->request->set('ajax_page_state', ['libraries' => \implode(',', $cumulative_assets->getAlreadyLoadedLibraries())]); ``` Core reads the value from `attributes`, never from `request`: - **`Drupal\Core\Ajax\AjaxResponseAttachmentsProcessor`** line 92: `$request->attributes->get('ajax_page_state')` - **`Drupal\Core\Render\HtmlResponseAttachmentsProcessor`** line 118: same - **`Drupal\Core\Asset\JsCollectionOptimizerLazy`** line 118: same - **`Drupal\Core\Asset\CssCollectionOptimizerLazy`** line 110: same `Drupal\big_pipe\Render\BigPipe`, which `TraceableBigPipe` overrides, uses `attributes` in both of the equivalent places (lines 420 and 564). The two copied methods in `TraceableBigPipe` have fallen out of sync with it. ## Steps to reproduce 1. Install Drupal 11.4 with `big_pipe` and `webprofiler` both enabled. 2. Place any block that is auto-placeholdered by BigPipe and relies on a `Drupal.behaviors` implementation. The AI Chatbot (DeepChat) block from `ai_chatbot` is a convenient example, since it is uncacheable and its click-to-open handler lives in a behavior. 3. Log in and load a page containing that block. ## Observed result The block renders but its JavaScript never runs. Measured on the page described above: | Check | With the bug | Expected | | --- | --- | --- | | `data-once` on the block element | `null` | set by the behavior | | `typeof Drupal.bigPipe` | `undefined` | `object` | | `Object.keys(Drupal.behaviors).length` | 7 | 23 | | `script[src*=jquery]` elements | 2 | 1 | There is no console error, which makes this hard to diagnose. The markup is present and correct, so the block simply looks unresponsive. Uninstalling either `big_pipe` or `webprofiler` makes the problem disappear, which is what points at the interaction between the two. ## Proposed resolution Set `ajax_page_state` on `$fake_request->attributes` in both methods, matching core. The patch is in the first comment below. Applying it restores every value in the table above to the expected column, with `webprofiler` and `big_pipe` both enabled and the toolbar still fully populated. A longer-term option worth considering: `TraceableBigPipe` currently duplicates the bodies of `sendPlaceholders()` and `sendNoJsPlaceholders()` from core, which is what allowed the drift. If the tracing hooks can be added around a `parent::` call, or core can be asked for a smaller extension point, this class of bug goes away. ## Environment - Drupal 11.4.5 - webprofiler 11.2.1 - PHP 8.4