SSR_BOUNDARY_WATERFALL
A <Loading> boundary needed 3+/4+ render passes — 2+/3+ sequential async waits (dev).
What you saw
- Kind:
ssr - Severity:
info(advisory, delivered on the diagnostics channel and never printed) orwarn(code that works but is structurally wrong or expensive)
The console report opens with [SSR_BOUNDARY_WATERFALL] and the message, then an in line naming the owners that enclose the subject, root first, and an at line with the source location when the code was compiled with one.
In a captured artifact the same finding is an event with code: "SSR_BOUNDARY_WATERFALL", ownerPath, and loc.
Diagnostics explains each line.
Why it fires
A <Loading> boundary rendered in data.passes passes — discovery, then one per wait — and each pass past the first is a read that could only start once the previous pass's async answered: passes - 1 sequential waits, data.sequentialMs end to end.
It applies the client's origin rule: a wait whose work had all started before the previous wait landed is parallel, not a link, and is left out (data.parallelWaits).
That is how nested route levels read: the router starts every matched level's lazy() import and preload together, and the boundary only meets each level a pass later.
The start comes from a markFlight stamp (lazy() stamps its import, Solid Router's query() its fetches); an unstamped promise counts as starting when the boundary meets it.
As on the client, a layer that hands out work it started earlier without stamping it (a request cache's wrapper promise) can still read as a chain; it should call OBSERVE.attribution.markFlight on what it hands out.
The server runtime reports on the same channel, with the same in <App> › <Page> line.
Two groups.
Findings (SSR_RENDER_ERROR_CONTAINED, SSR_SUBTREE_ABANDONED, SSR_STREAM_ABANDONED, LATE_HEADER_WRITE, DYNAMIC_ASYNC_COMPONENT, SERVER_ERROR_SANITIZED, FRAME_MARKER_CORRUPTED) are facts about a render that exist in observe builds too — an APM sees them in production; in dev they print.
Checks (the rest, SSR_BOUNDARY_WATERFALL and SSR_CLIENT_CONTENT_MASKED included) are dev-only guidance.
A captured artifact from a server render carries both.
How to fix it
The same repairs apply, in the same order: derive both reads from the same inputs so they start together (read ALL async sources before using any), or, if the dependency is intrinsic, preload the dependent data or join the requests.
Two waits are info — a lead; three or more warn.
The boundary is data.boundary; a captured artifact has its record in artifact.records.boundary (same id) and the server-function calls under it in artifact.records.invocation (boundary field).
In tests
captureArtifact from @solidjs/diagnostics runs a scenario with the diagnostics channel open and returns the events it saw.
expectNoDiagnostics(artifact) fails while SSR_BOUNDARY_WATERFALL is among them, with the events as evidence; after the fix, the code is gone from artifact.diagnostics.
Check for regressions in tests shows the loop and the Vitest matcher form.
Learn more
- Diagnostics: every code, with its kind, severity, and trigger.
- Debugging reactivity: how to read a report and what each group of codes points at.