UNTRACKED_READ_AFTER_AWAIT
Async computation first read a signal/memo/store key after an await; never a dependency (dev; V8 engines only).
What you saw
- Kind:
async - Severity:
warn(code that works but is structurally wrong or expensive)
The console report opens with [UNTRACKED_READ_AFTER_AWAIT] 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: "UNTRACKED_READ_AFTER_AWAIT", ownerPath, and loc.
Diagnostics explains each line.
Why it fires
An async computation read a signal, memo, or store property for the first time after an await.
Only reads before the first await are tracked, so the computation keeps its old result when that value changes.
How to fix it
Read the value before the first await (capture it in a local), or wrap the read in untrack() if a one-time value is intended.
Dev-only and V8-only (Chromium browsers, Node, Deno, Bun); Firefox and Safari never report it, so treat it as complementary to lint — it follows the read into helpers, .then callbacks, and awaited utilities that lint cannot see.
async function* bodies are not covered.
Warns once per computation per signal/memo and once per store; a read inside an effect callback, cleanup, or action() body that the continuation itself triggered is not blamed on it.
In tests
captureArtifact from @solidjs/diagnostics runs a scenario with the diagnostics channel open and returns the events it saw.
expectNoDiagnostics(artifact) fails while UNTRACKED_READ_AFTER_AWAIT 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.