IMMUTABLE_UPDATE_IN_STORE
Store container replaced by a mostly-identical copy (attribution enabled).
What you saw
- Kind:
perf - Severity:
warn(code that works but is structurally wrong or expensive)
The console report opens with [IMMUTABLE_UPDATE_IN_STORE] 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: "IMMUTABLE_UPDATE_IN_STORE", ownerPath, and loc.
Diagnostics explains each line.
Why it fires
A store setter replaced a container with a fresh object/array whose leaves are mostly the same values: draft.user = { ...draft.user, name }, draft.items = [...draft.items, x], draft.items = draft.items.filter(…).
The store tracks leaves; a fresh container makes every reader of the container's path (anything under user) re-run for the one leaf that moved.
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
Repair: mutate the draft — draft.user.name = name, draft.items.push(x), draft.items.splice(i, 1) — so only readers of the touched key or index re-run.
Data arriving from outside (a fetch result for the same records) merges with reconcile(data, "id")(draft.items), which keeps identity for records that did not change.
Once per store path; data.unchanged/total says how much of the container was carried over.
In tests
captureArtifact from @solidjs/diagnostics runs a scenario with the diagnostics channel open and returns the events it saw.
expectNoDiagnostics(artifact) fails while IMMUTABLE_UPDATE_IN_STORE 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, and expectNoWaste(artifact) fails on re-runs whose result was unchanged.
Both read 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.