Diagnostics

STACKED_HOLDS

3+ interactions were waiting in one hold when it committed — repeats piled behind the same source (attribution enabled).


What you saw

  • Kind: responsiveness
  • Severity: warn (code that works but is structurally wrong or expensive)

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


Why it fires

data.interactions interactions were waiting in the same hold when it committed: the person clicked or typed again while the first answer was in the air, and the runtime folded every repeat into one wait on the same source (data.blockers). The pile is the symptom; the hold's own verdict is the cause — check the SILENT_HOLD/LONG_HOLD entry for the same hold first.

Responsiveness (from the attribution engine)

The runtime did the correct thing; the user saw nothing while it did. These fire only while attribution is enabled.


How to fix it

Then stop the repeats at the control:

  • Read isPending(() => blocker()) where the control renders and disable or dim it while the flight is out, so a second click is not possible.
  • For typed input, debounce so a burst of keystrokes is one write.
  • Show progress (latest() of the input, an optimistic value) so the person does not click again because nothing moved.

Do NOT block input by removing the hold or making the write synchronous; the repeats are a reaction to silence, and the hold is what keeps the screen consistent while the answer arrives.


In tests

captureArtifact from @solidjs/diagnostics runs a scenario with the diagnostics channel open and returns the events it saw. expectNoDiagnostics(artifact) fails while STACKED_HOLDS 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.
  • Attribution: the engine whose records explain a re-run, a hold, or a waterfall.
Last updated: 10/15/26, 10:07 PMEdit this pageReport an issue with this page