SILENT_HOLD

Write held 100ms+/200ms+ by pending async with no on-screen acknowledgement (attribution enabled).

---

What you saw

• Kind: responsiveness
• Severity: info (advisory, delivered on the diagnostics channel and never printed) or warn (code that works but is structurally wrong or expensive)

The console report opens with [SILENT_HOLD] 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: "SILENT_HOLD", ownerPath, and loc. Diagnostics explains each line.

---

Why it fires

A write landed on async work, so the runtime held it (and everything derived from it) until the data came back — that hold is correct; it is what keeps the screen from tearing. But for the whole wait nothing on screen acknowledged it: no isPending()/latest() reader downstream of the write or its blocker, no optimistic value, no affects() mark, and no effect ran at all. From the user's side the click was dead for the duration in the message — which, when the write came from a JSX event handler, starts with what they did (click on button#next "Next →" wrote "page" (1 → 2)) and is measured from that event.

---

How to fix it

The fix is ALWAYS to add feedback, never to remove the hold:

• Show the wait: read isPending(() => blocker()) (the blocker is named in the message) or isPending(() => derivedFromIt()) in the affected UI and render a busy state from it.
• Reveal the input immediately: latest(source) shows the NEW value of the held write (a page number, a filter, a query string) while the data catches up, so the control the user touched reflects the touch.
• Predict the outcome: createOptimistic/createOptimisticStore written alongside the real write (or inside the action) shows the expected result now and reverts on failure. For actions this is the primary repair — the message says "an action held" when the hold came from one.
• Do NOT: move the write off the async path, wrap it in untrack, or split the read so the write commits "faster" — that trades the hold for a torn screen (old data under new controls).

Thresholds sit at the strict end of the band on purpose: the engine measures to the commit, not the paint, so every number is a floor on what the user saw. From holds.infoMs (default 100ms — past "feels instant") the event is info-severity, structured channel only; from holds.warnMs (default 200ms — the INP "good" ceiling) it reaches the console. attribution.history("hold") lists every hold (acknowledged or not) with what was held, what blocked it, and which affordances answered it; each carries the engine's verdicts as silent/long fields. When the silent hold's tail also crossed the long-hold threshold (data.long: true) the message carries the LONG_HOLD repair as well — the fallback is the honest UI at that length.

---

In tests

captureArtifact from @solidjs/diagnostics runs a scenario with the diagnostics channel open and returns the events it saw. expectNoDiagnostics(artifact) fails while SILENT_HOLD is among them, with the events as evidence; after the fix, the code is gone from artifact.diagnostics. expectNoSilentHolds(artifact) fails on every hold the screen never acknowledged, at any length, not only the ones long enough to warn. In a budget file the same check is maxSilentHoldMs: 0. 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.