Re-entrant layout builds silently corrupt page structure since ACP2E-4040 (isolated reader context)

[rhoerr]

Summary

Since 6194581 (ACP2E-4040, imported from upstream Magento 2.4.9), building the same shared layout twice within one request silently corrupts the generated structure: blocks scheduled into a container by an <update>-included handle lose their parent and disappear from the rendered page.

Before that change, Magento\Framework\View\Layout::generateElements() handed the shared Reader\Context to the generator pool, which consumed the ScheduledStructure in place — after a build it was empty, so a (rare but possible) second build re-interpreted into clean state. Since ACP2E-4040, generation runs on a clone (createIsolatedReaderContext()), so after a build the shared context retains all scheduled rows and materialized paths. A second generateElements() re-interprets the layout XML on top of that dirty state, and Layout\ScheduledStructure\Helper::_overrideElementWorkaround() treats the re-read declarations as overrides of the leftover rows — silently destroying the children scheduled under their paths.

How a double build happens with core code only

1. A controller uses the common pattern $resultPage->getConfig()->getTitle()->set(...). Page\Config::getTitle() triggers a full early layout build.
2. During that build, block generation lazily instantiates a class depending on the deprecated Magento\Framework\App\ViewInterface (e.g. Magento\Customer\Helper\Session\CurrentCustomer, injected by a block or view model). App\View::__construct eagerly runs $pageFactory->create(true); the throwaway Result\Page constructs a Page\Builder, whose constructor unconditionally calls $this->pageConfig->setBuilder($this) on the shared Page\Config — replacing the already-built builder.
3. Result\Page::render() → publicBuild() → the swapped-in builder (isBuilt = false) re-runs loadLayoutUpdates() / generateLayoutXml() / generateElements() on the same shared layout instance.
4. The second pass corrupts the structure. Log fingerprint (developer mode):
   Broken reference: the 'google_gtag_analytics' tries to reorder itself towards 'head.hyva-scripts', but their parents are different: 'head.additional' and '' respectively.

The eager page creation in App\View and the builder swap in Page\Builder::__construct are long-standing quirks; they were harmless while a second build started from a consumed (empty) reader context. ACP2E-4040 made re-entrant builds destructive.

Observed impact

On a Hyva storefront (Mage-OS 3): the head.additional children contributed by the theme's default_hyva handle (head.js, head.hyva-scripts, speculationrules) vanish from the page, breaking all hyva.* JavaScript on affected routes (e.g. third-party customer-account controllers that set the title early and then render blocks using CurrentCustomer). Any layout where a handle included via <update handle="..."/> schedules blocks into a re-declared container is susceptible.

Suggested direction

Either make re-entrant builds safe again (reset the shared Reader\Context's ScheduledStructure and the layout's Data\Structure when generateElements() runs on an already-built layout), or prevent the rogue rebuild at its sources: create App\View's page lazily in getPage() instead of the constructor, and/or don't let Page\Builder::__construct replace an already-built builder on the shared Page\Config.

Workaround

DI-detach App\View's eager page from the shared Page\Config for injection points that are constructed mid-build: a virtual Result\Page with isIsolated=true plus a non-shared Page\Config (via a virtual Template\Context), wired into App\View's pageFactory argument for e.g. CurrentCustomer::$view.

Identified on a client site with Mage-OS 3.4 + Hyva Theme + Amasty B2B suite, on an account-area controller.

[rhoerr]

For anyone hitting this, here is the DI workaround in full (frontend di.xml of any module). It detaches the deprecated App\View's eagerly-created throwaway page from the shared Page\Config, so its Page\Builder can no longer replace the already-built builder:

<virtualType name="DetachedPageConfig" type="Magento\Framework\View\Page\Config" shared="false"/>
<virtualType name="DetachedTemplateContext" type="Magento\Framework\View\Element\Template\Context">
    <arguments>
        <argument name="pageConfig" xsi:type="object" shared="false">DetachedPageConfig</argument>
    </arguments>
</virtualType>
<virtualType name="DetachedResultPage" type="Magento\Framework\View\Result\Page">
    <arguments>
        <argument name="context" xsi:type="object">DetachedTemplateContext</argument>
        <argument name="isIsolated" xsi:type="boolean">true</argument>
    </arguments>
</virtualType>
<virtualType name="DetachedResultPageFactory" type="Magento\Framework\View\Result\PageFactory">
    <arguments>
        <argument name="instanceName" xsi:type="string">DetachedResultPage</argument>
    </arguments>
</virtualType>
<virtualType name="DetachedAppView" type="Magento\Framework\App\View">
    <arguments>
        <argument name="pageFactory" xsi:type="object">DetachedResultPageFactory</argument>
    </arguments>
</virtualType>
<type name="Magento\Customer\Helper\Session\CurrentCustomer">
    <arguments>
        <argument name="view" xsi:type="object">DetachedAppView</argument>
    </arguments>
</type>

Notes:

• The last <type> block targets the specific lazy ViewInterface consumer that triggered the rebuild in our case (CurrentCustomer, injected by a view model rendered mid-build). Repeat it for any other consumer that gets constructed during a layout build (e.g. Magento\Wishlist\CustomerData\Wishlist).
• Deliberately not applied as a global preference for ViewInterface: legacy $this->_view controller flows expect the shared instance, and only mid-build lazy construction is harmful.
• A plain Magento\Framework\App\View\Proxy is NOT sufficient: CurrentCustomer::getCustomer() calls $view->isLayoutLoaded() during rendering, which materializes the proxy — and the hijack — at the same point. isLayoutLoaded() behaves identically on the detached instance (always false in modern result-object flows), so behavior is unchanged.