FALLBACK_FLASH
A Loading fallback showed for under 150ms — feedback for a wait too short to need it (attribution enabled).
What you saw
- Kind:
responsiveness - Severity:
info(advisory, delivered on the diagnostics channel and never printed)
The console report opens with [FALLBACK_FLASH] 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: "FALLBACK_FLASH", ownerPath, and loc.
Diagnostics explains each line.
Why it fires
A Loading fallback appeared and vanished inside 150ms (data.shownMs): the data was nearly there, and the spinner read as a flicker.
This is the other end of SILENT_HOLD — too much feedback for too little wait — and it is info, a count to read (feedback().fallbacks[] .flashes has the total per boundary).
The runtime did the correct thing; the user saw nothing while it did. These fire only while attribution is enabled.
How to fix it
Repairs:
- Preload or cache the data so it is present before the boundary asks (
markFlighta preload started on hover or route match). - Lift the read above the boundary when the parent already waits, so the child boundary never shows.
- For a boundary that has revealed once, let a later update hold instead of re-showing the fallback — that is the default; a flash on update means
onis keyed to something that changes more often than the data.
Do NOT add a minimum-display timer to the fallback; that trades a flicker for a wait.
In tests
captureArtifact from @solidjs/diagnostics runs a scenario with the diagnostics channel open and returns the events it saw.
expectNoDiagnostics(artifact) fails while FALLBACK_FLASH is among them, with the events as evidence; after the fix, the code is gone from artifact.diagnostics.
The assertion counts an info event like any other, so a scenario that accepts this one lists the code in its allow option.
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.
- Attribution: the engine whose records explain a re-run, a hold, or a waterfall.