Diagnostics

A diagnostic is a finding the runtime makes about your code while it runs: a reactive value read where nothing tracks it, a write from inside a computation, an effect that re-runs because of its own write, a wait the screen never acknowledged. Each finding carries a stable code, and every code has a page here that says what you saw, why it fires, and how to fix it.

A development build prints each finding to the console. An observe build delivers the same findings as events on OBSERVE.diagnostics without printing them, and a test captures them with captureArtifact from @solidjs/diagnostics so that expectNoDiagnostics(artifact) fails on a regression. A production build reports nothing.

Severity says what kind of finding it is: error is broken behavior, warn is code that works but is structurally wrong or expensive, and info is advisory, delivered on the diagnostics channel and never printed. Some codes fire only while the attribution engine is enabled, because they measure cost or waiting rather than correctness; their pages say so.

Read a report

One console entry per finding:

[STRICT_READ_UNTRACKED] Reactive value "title" read directly in <TodoRow> will not update. Move it into a tracking scope (JSX, a memo, or an effect's compute function).
  in <App> › <TodoList> › <TodoRow>
  at http://localhost:5173/src/components/TodoRow.tsx:18:3
[STRICT_READ_UNTRACKED] what it means and how to fix it: https://v2.solidjs.com/reference/solid-js/diagnostics/strict-read-untracked
[STRICT_READ_UNTRACKED] agent repair guide: node_modules/solid-js/skills/reactivity-diagnostics/SKILL.md#strict_read_untracked — https://github.com/solidjs/solid/blob/next/packages/solid/skills/reactivity-diagnostics/SKILL.md#strict_read_untracked

• The first line is the code in brackets and the message: what the runtime observed and, for most codes, what to change.
• The in line is the chain of owners from the root down to the scope that produced the finding: components as <Name>, computations by the name option you gave them or effect/computed by default. No in line means the subject has no named owner: a top-level scope, or an unowned primitive, which for the NO_OWNER_* codes is the finding itself. In a captured artifact the same chain is event.ownerPath.
• The at line is the source location of the innermost located node on that chain, file:line:col relative to the project root, as written by the compiler's sourceNames locations kind (on in development through @solidjs/vite-plugin). In a browser the path is printed under the dev server's origin, so the console links it to the Sources panel; on the server it is the bare path. In a captured artifact it is event.loc.
• When the finding is about a compiled JSX binding (an attribute, a class, a style, an inserted value), the entry also carries the element it writes as a second console argument: hover it to highlight the element on the page, click it to jump to the Elements panel.
• The first report of each code ends with a footer: the link to that code's page here, then the path of the repair skill installed with solid-js for an agent working in the repository.

Naming your memos and effects ({ name }) turns the trailing effect in the in line into something you can search for. Debugging reactivity walks through the common cases.

Codes