Intermittent "No hint path defined for [layouts]" on Filament panel pages (page-layout capture race in SupportPageComponents)

Livewire version

v4.4.2

Laravel version

v13.29.0

PHP version

8.5.9

Browser and operating system

Chrome on Ubuntu 26.04 lts

Describe the issue you're experiencing

Package: livewire/livewire Version: v4.4.1 and v4.4.2 (same behavior, diffed SupportPageComponents.php between them — no relevant change) Laravel Version: v13.26.1 / v13.29.0 (both affected) PHP Version: 8.5.9 Also using: filament/filament v5.7.6 (filament/support requires livewire/livewire: ^4.1)

Problem description

Filament panel pages intermittently throw:

InvalidArgumentException
No hint path defined for [layouts].
vendor/laravel/framework/src/Illuminate/View/FileViewFinder.php:111

This is the same underlying symptom as filamentphp/filament#19020 (fixed on the Filament side in filamentphp/filament#19049 by scaffolding resources/views/layouts/app.blade.php), but that fix only applies to the "individual components" installer flow. Filament panels never scaffold that file, because Filament\Pages\BasePage::render() always calls ->layout(...) explicitly and should never need the config('livewire.component_layout') default. In our case it does anyway, intermittently.

What we found tracing SupportPageComponents.php

interceptTheRenderOfTheComponentAndRetreiveTheLayoutConfiguration() opens a listener window around app('livewire')->mount(...):

$handler = once(function ($target, $view, $data) use (&$layoutConfig, &$slots) {
    ...
    $layoutConfig = $view->layoutConfig ?? new PageComponentConfig;
    ...
});
on('render', $handler);
on('render.placeholder', $handler);
$callback(); // mounts + renders the page component tree
off('render', $handler);
off('render.placeholder', $handler);

once() here (Livewire's own helper in src/helpers.php, not Laravel's global one) only lets the first render/render.placeholder event within this single call actually run the capture logic — intentionally, per the comment, so nested child components rendered during the same page mount don't overwrite the parent page's layout.

We instrumented this with a separate (non-once()-guarded) listener on the same render event to log component class + whether $view->layoutConfig was set, across dozens of real requests. In every render order we could capture, the outer Filament page (with its correctly-set layoutConfig) fired first, and nested components (Filament\Livewire\Topbar, Sidebar, Notifications) correctly fired after with no layoutConfig — i.e. we could not directly catch a nested component winning the guard. However, we could independently confirm (by watching the log around the exact timestamp of a spontaneous production-side failure) that on the failing request, our unguarded listener never fired at all — meaning no render event fired for any component during that mount() call, yet HandlesPageComponents::__invoke() still proceeded to renderContentsIntoLayout() with an empty/default PageComponentConfig, falling back to config('livewire.component_layout') ('layouts::app' by default).

We were not able to build a reliable, deterministic repro — this reproduces roughly a handful of times per hour of real interactive usage against a live Filament panel (both a custom auth-guard patient portal and the standard tenant admin panel), but did not reproduce under scripted/headless browser automation performing the same actions repeatedly. This suggests a timing-sensitive condition inside the mount()/render lifecycle that fast, deterministic scripted interaction doesn't reliably hit.

Workaround in place

We added resources/views/layouts/app.blade.php (content matching Filament's own post-#19049 scaffolding stub) so that when this fallback path is hit, the request still renders correctly instead of crashing — it degrades to the generic layout instead of the intended Filament chrome for that one request. This does not address the underlying race, only its consequence.

Additional context

Also checked and ruled out as unrelated:

• Not fixed by upgrading v4.4.1 → v4.4.2 (diffed SupportPageComponents.php, no behavioral change).
• The same once()/render-capture mechanism exists unchanged since v4.0.0.
• Not caused by tenancy middleware (stancl/tenancy) in our app — that completes during the middleware phase, before Livewire's render-listener window opens.

Code snippets to reproduce the issue

Steps to reproduce

We don't have a minimal, deterministic reproduction repo yet — this is reported as a real-world, intermittent occurrence with supporting evidence rather than a guaranteed repro, because we could not force it on demand. Environment where it occurs:

• Filament v5.7.6 panel (multiple panels, multiple guards) with pages extending Filament\Pages\Page / Filament\Resources\Pages\*.
• Occurs on GET requests to full-page Filament routes (both direct navigation and following a 302 redirect, e.g. an expired-auth redirect to a login page).
• Occurs across different page types (a Filament resource list page with a table filter, a Filament page with a searchable Select field, and a Filament auth Login page) — doesn't appear tied to one specific field/component type, just to the general page-render lifecycle.

Screenshots/screen recordings

How do you expect it to work?

Expected behavior

The outer page's ->layout(...) call should always win the capture, since BasePage::render() calls it synchronously before returning the View — the fallback to config('livewire.component_layout') should not be reachable for a component that always sets a layout.

Please confirm (incomplete submissions will not be addressed)

• I have provided easy and step-by-step instructions to reproduce the bug.
• I have provided code samples as text and NOT images.
• I understand my bug report will be removed if I haven't met the criteria above.