Infinite recursion / fatal error rendering the front-end page when main_page_content is nested inside a component's slot

Thanks for the branch. I gave it a try — here's what I found.

The shutdown logger did not fire, but not because the nesting detection is wrong. I checked nestedRegionWrappers() separately, cold, via reflection against our real page layout's actual source tree:

$wrappers = [
  'main_page_content' => 'lbeabdd_theme:container',
];

So the detection is correct and matches exactly what we described (main_page_content nested inside our generic "Container" component's slot).

The reason nothing got logged is that this time the crash did not surface as a classic PHP fatal error. It came out as an uncaught \Error thrown from inside the Composer autoloader itself:

Uncaught PHP Exception Error: "Maximum call stack size of 2048000 bytes
(zend.max_allowed_stack_size - zend.reserved_stack_size) reached.
Infinite recursion?" at /var/www/html/vendor/composer/ClassLoader.php line 425

error_get_last() only records classic PHP errors/warnings/fatals reported through the E_* mechanism — it does not see an uncaught Throwable that a custom exception handler (or, here, nothing at all further up) deals with. So logFatalAfterNestedRegions() correctly finds nothing to log in this case, even though the fatal did happen.

What's notable is that the exact failure mode is not stable across requests on our end. We've now seen all of the following, on the same page, depending on the run:

• A raw compile-time fatal ("Maximum call stack size ... reached during compilation. Try splitting expression") blamed on justinrainbow/json-schema's InvalidArgumentException.php.
• An "Allowed memory size exhausted" fatal in Drupal\Core\Render\Element\InlineTemplate.
• An uncaught \Error ("Infinite recursion?") thrown from Composer\Autoload\ClassLoader::loadClass().

That's consistent with what we already suspected: it's not a clean, bounded self-recursion of one template (a re-entrancy guard we added earlier never triggered), but something that keeps growing until whatever happens to need compiling/autoloading/allocating next is what tips it over — hence the different file/line every time. It also probably explains why a minimal fragment doesn't reproduce for you: the failure point likely depends on the exact depth reached, which depends on the rest of the page (other components, field values, autoloader/opcache state), not just the container/main_page_content nesting in isolation.

I'm attaching:

• full-backtrace.txt — a complete, non-truncated backtrace (493 frames) captured earlier by temporarily lowering xdebug.max_nesting_level so the process aborts cleanly instead of dying outright. This shows the actual repeating call pattern through ComponentElementBuilder, Renderer::doRender() and InlineTemplate::preRenderInlineTemplate().

I'd rather not publish our real page-layout/entity-view-display export as-is (it has business-specific block placements, visibility conditions tied to real content, etc.), but I'm happy to answer specific questions about the structure, or to test another diagnostic branch if you can point at what would help narrow it down further (for instance, something that dumps the actual size/depth of the render array right before it's handed to the component, rather than relying on catching the fatal after the fact).

Confirmed — updated to drupal/display_builder 1.0.x HEAD (974e71c, which includes your 9a30586 fix for #3620706) and drupal/ui_patterns 2.0.21. The page renders correctly now, including right after a fresh drush cr (see below). Happy for this to be closed as a duplicate of #3620706.

1. The view in that page-layout slot

Yes, exact match. The techniques_soins view (a "bloc" display used as a block in the page layout) uses the "Component (UI Patterns)" style plugin, wrapping rows in our generic lbeabdd_theme:container component, with the row content fed by a view_rows source in the component's slot:

style:
  type: ui_patterns
  options:
    ui_patterns:
      ui_patterns:
        component_id: 'lbeabdd_theme:container'
        slots:
          content:
            sources:
              - source_id: view_rows
                source:
                  ui_patterns_views_field: ''
row:
  type: 'entity:taxonomy_term'
  options:
    view_mode: teaser

We have a second view (a "blog" listing block) with the same pattern, using ui_suite_daisyui:grid_cols instead of our own container, also with a view_rows source in a slot. Both are placed as blocks inside the page layout's content region, alongside (not wrapping) the main_page_content/container source.

2. Cold cache vs. "root placement avoids the crash"

Retested this properly now that I understand what to look for. With drupal/display_builder updated to 1.0.x HEAD:

• drush cr, then immediately request the front page: 200, correct content, correct size.
• drush cr again, immediately request again: same result.
• Node page with the same views blocks in its region: 200 as well.

So on a cold cache, with the fix applied, it's fine. I did not have a chance to specifically re-verify the earlier "root vs. nested main_page_content" observation against a cold cache on the old broken code before updating — given your explanation (the loop never touches display_builder_page_layout, and Views output being render-cached tag-based would render fine warm and loop cold), I think what we actually observed was exactly that: our first tests after pinning back to the last-good display_builder commit happened to hit a warm Views cache, and later tests exercising the nested-slot fatal happened to hit it cold. That fits your explanation better than any theory involving the page layout itself, especially now that the backtrace you read confirms display_builder_page_layout isn't on the stack at all. I don't think we can respeak reliably for a coincidence we didn't control for at the time — sorry for the red herring, and thanks for tracking it down from the backtrace alone.