OPTIMISTIC_REVERTED
An optimistic value the screen showed was replaced by a different one — reverted at settle, or superseded by the truth (attribution enabled).
What you saw
- Kind:
responsiveness - Severity:
info(advisory, delivered on the diagnostics channel and never printed)
The console report opens with [OPTIMISTIC_REVERTED] 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: "OPTIMISTIC_REVERTED", ownerPath, and loc.
Diagnostics explains each line.
Why it fires
An optimistic value the screen showed was replaced by a different one: the person saw the guess, then the correction.
data.how says which road: reverted — the action ended without the guess coming true and the value snapped back to what it covered; superseded — the real value landed and differed from the guess (the server counted differently, rejected part of the input).
Both are the runtime doing exactly what optimistic UI promises, which is why this is info and never reaches the console; it is a count to read, not a warning to silence.
The runtime did the correct thing; the user saw nothing while it did. These fire only while attribution is enabled.
How to fix it
Read it two ways:
- One source, many reverts: the failure is common and the UI is hiding it. Show the failure where the value renders — catch in the action and write an error the UI reads, or put the reader behind an
Erroredboundary — so the snap-back is explained rather than silent. - One source, many supersessions: the guess is systematically wrong for this input (it ignores what the server adds or normalizes). Guess less: write only the part of the value the client can know, or none, and read
isPending()for the rest.
Do NOT "fix" a revert by writing the guess to the authoritative signal so it cannot revert — that is not optimistic UI, it is lying to the user about what happened.
The runtime's own optimistic nodes — the isPending()/latest() companions that acknowledge a hold — are never reported; only values you wrote optimistically are.
Optimistic stores are not covered yet; a store-path revert shows up only as the reader's re-run.
In tests
captureArtifact from @solidjs/diagnostics runs a scenario with the diagnostics channel open and returns the events it saw.
expectNoDiagnostics(artifact) fails while OPTIMISTIC_REVERTED is among them, with the events as evidence; after the fix, the code is gone from artifact.diagnostics.
The assertion counts an info event like any other, so a scenario that accepts this one lists the code in its allow option.
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.