HUGE_FAN_OUT
One change reached 2000 live subscribers (always on), or 250 — fanOut — on a stamped root write (attribution enabled).
What you saw
- Kind:
graph - Severity:
warn(code that works but is structurally wrong or expensive)
The console report opens with [HUGE_FAN_OUT] 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: "HUGE_FAN_OUT", ownerPath, and loc.
Diagnostics explains each line.
Why it fires
One value has very many subscribers, so a single change re-runs all of them (data.count).
Always on from 2000; while attribution is enabled the same code fires from fanOut (default 250) on a stamped root write, and data.write says which — a write, a refresh, or an async landing.
Classic signature: every row of a list comparing against one selected id.
These fire only while attribution is enabled and describe cost, not incorrect behavior. The numbers in the message are measurements, not guesses.
How to fix it
Invert the question: keep the answer in a store used as a map keyed by id (selected[row.id] instead of row.id === selectedId()), so each consumer reads its own key and only the keys that flipped update.
When that map is derived from other state, createProjection builds 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 HUGE_FAN_OUT is among them, with the events as evidence; after the fix, the code is gone from artifact.diagnostics.
expectRerunBudget(artifact, max, { scope }) bounds how often a named scope may re-run after a write.
It reads the attribution records, which captureArtifact collects unless attribution: false is passed.
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.