feat(signals): OPTIMISTIC_REVERTED — an optimistic value the screen showed was replaced - #3607
Merged
Merged
Conversation
🦋 Changeset detectedLatest commit: db043d4 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Merging this PR will not alter performance
Comparing 
Footnotes
|
This was referenced Sep 23, 2026
ryansolid
marked this pull request as ready for review
September 24, 2026 00:45
ryansolid
force-pushed
the
feat/optimistic-reverted
branch
from
September 24, 2026 01:32
4b4aec4 to
cab9f3f
Compare
…he correction An optimistic override the screen displayed is replaced by a different value on two roads: the guess lifts at settle back to the committed value it covered (the action failed, or never wrote what it promised), or an authoritative value lands that differs from it. Both are the runtime doing what optimistic UI promises, so the finding is `info` and structured-channel only — a count that grows for one source is what says the guess, or the failure rate, is wrong. Judged by the node's own equality. `AttributionHooks.optimisticReverted(el, shown, truth, how)` is the seam, fired from supersedeOverride (how derived from whether a landing is staged) and from the non-superseded drop in resolveOptimisticNodes. Not covered yet, and said so: optimistic stores, and the interaction that wrote the guess (optimistic writes bypass the write hook, so the node carries no origin). The plan marks item 2 satisfied by #3580 — `at` equals the Event Timing entry's `startTime`; `interactionId` is not readable at dispatch. Size: engine +266 B, tier +38 B; the engine cap moved with a note. Co-Authored-By: Claude via Cursor <cursoragent@cursor.com> Co-authored-by: Cursor <cursoragent@cursor.com>
….45 -> 31.65 KB Co-authored-by: Claude via Cursor <noreply@cursor.com>
ryansolid
force-pushed
the
feat/optimistic-reverted
branch
from
September 24, 2026 06:20
cab9f3f to
0b69a7f
Compare
…mistic nodes The finding fired on every acknowledged hold: isPending()'s companion is an optimistic signal that goes true while pending and back to false at commit by design — the acknowledgement SILENT_HOLD asks for — so the repair for one finding produced another. The check now skips companions and derived overrides by the predicate the hold census already uses (`isCompanion`), and `optimisticReverts: false` disables it like the other verdicts. The regression test is the acknowledged hold itself (isPending and latest readers over a held write): silent with the guard, one false finding without it. Co-Authored-By: Claude via Cursor <cursoragent@cursor.com> Co-authored-by: Cursor <cursoragent@cursor.com>
…ne 31,625 B under the 31.65 KB cap The `optimisticReverts` option and the `isCompanion` skip in checkOptimisticRevert are +35 B on the engine scenario (31,590 -> 31,625 B). The cap holds; the note records the new measurement. Tier unchanged at 17,618. Co-authored-by: Claude via Cursor <cursoragent@cursor.com>
Coverage Report for CI Build 35970793844Coverage remained the same at 73.134%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Item 3 of
documentation/plans/responsiveness-findings-plan.md; item 2 marked satisfied by #3580 in the same plan edit.What it says
An optimistic value (
createOptimistic) the screen displayed was replaced by a different one.data.hownames the road:reverted— nothing new landed and the override lifted back to the committed value it covered (the action failed, or never wrote what it promised);superseded— an authoritative value landed that differs from the guess. Both are correct by construction — the revert is the feature — so this isinfo, structured channel only, on whenever the engine is enabled: a count that grows for one source is what says the guess or the failure rate is wrong. Judged by the node's ownequals, so a structurally equal correction is silent.data:source,shown,truth(40-char previews),how; subject is the node.The seam
AttributionHooks.optimisticReverted(el, shown, truth, how), fired fromsupersedeOverride(how derived from whether a landing is staged in_pendingValue) and from the non-superseded differing drop inresolveOptimisticNodes. Both sites sit outside anytry,__OBSERVE__-gated.Not covered, on purpose
_clearOptimisticStores; a per-path comparison is its own change.optimisticWrite, which bypasses thewritehook, so the node carries no origin stamp. Stamping them touches the interaction accounting (writes, hold membership) and should be decided separately.Public API
AttributionHooksgainsoptimisticReverted(...).DiagnosticCodegains"OPTIMISTIC_REVERTED".AttributionOptionsgainsoptimisticReverts?: boolean(defaulttrue;falsedisables the finding, like the other verdict options).Never judged: the runtime's own optimistic nodes
The first cut fired on every acknowledged hold:
isPending()'s companion is an optimistic signal that goestruewhile pending and back tofalseat commit by design — the acknowledgementSILENT_HOLDasks for — so the repair for one finding produced another (two@solidjs/diagnosticsharness tests caught it).checkOptimisticRevertnow skips companions (_parentSourceset:isPending/latest) and derived overrides (CONFIG_DERIVED_OVERRIDE: a lane pass's result, not a written guess) by the sameisCompanionpredicate the hold census already uses. UsercreateOptimisticvalues are unaffected — a written guess is never a companion, andoptimisticWriteclears the derived bit. Regression test: an acknowledged hold withisPendingandlatestreaders is silent; without the guard it produces one false finding per held write.Size (re-measured at landing over #3604/#3623/#3613/#3619/#3608): engine 31,625 B against
next's 31,368 (+257 B: +222 for the finding, +35 for the companion guard), cap 31.45 → 31.65 KB with note; tier unchanged at 17,618. Tests: 7 new (reverted, superseded, confirmed-silent, custom-equality-silent, acknowledged-hold-silent,optimisticReverts: false, no-engine inert); signals 3684 / diagnostics 34 / solid 780 / web 944+1150+248 (native and babel) green.