2.0.0-rc.8 optimistic update first reveals after its action body has finished

[GabbeV]

Describe the bug

An action sets an optimistic value and finishes its body after 500ms. The runtime waits for the optimistic value's async derivation to finish before starting the revert: both values first become 1 after one second, then return to 0 after another second.

Your Example Website or App

https://s.olid.uk/id/TCIEZ0gPR5SHBPGWcBaueQ

Steps to Reproduce the Bug or Issue

1. Wait for initialization.
2. Click Run.
3. The action body finishes after 500ms.
4. Value and Details become 1 after one second, then return to 0 after another second.

Expected behavior

Attempt the revert when the action's own work finishes. Any observed async work triggered by that revert can delay its commit, but it should not first wait for the obsolete optimistic request to finish.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Firefox

Additional context

Related to #3331, fixed by #3370. That fix starts correction when a new authoritative source value arrives. Here the authoritative value stays 0 and the action body simply finishes.

Is the remaining wait intentional in this case? My expectation is that reverting discovers which authoritative work is observed, without first completing the optimistic work.

Reproduced on next at 1643d2a and #3425 at 9fa294f, in development and production builds.

[ryansolid]

Confirmed and fixed in #3434 — your expected behavior is implemented as stated: the revert is attempted when the action's own work finishes, and the obsolete optimistic request is not waited on.

Rule: once the action bodies have ended and nothing authoritative is in flight — no override node's own source, no held plain load the action asked for — each override's truth supersedes it, the same way an arriving differing source value does (#3331/#3370). The graph re-derives from the truth right then as the transaction's held work, and the transaction settles when that lands. The override stays on screen until that commit, so nothing tears and the obsolete frame never shows. In your repro: Pending: true at the click, Pending: false at 3500 with both values still 0; before, Value: 1 | Details: 1 flashed at 3000 and the correction landed at 4000.

The carve-outs are the cases where the truth genuinely isn't known yet: a refresh of the optimistic value's own source inside the action holds through (the landing confirms or corrects), and a co-written pending flag stays up through a plain load the action asked for (setSaving(true); setPage(2)).

— Claude via Cursor

[ryansolid]

Fixed in 25c5064 (#3434), merged to next — ships in the next rc.

Your expectation was the right rule and it's now the A18 body-end corollary: once the action bodies have ended and nothing authoritative is in flight — no override node's own source, no held plain load the action asked for — each override's truth supersedes it immediately, exactly as an arriving differing truth does (#3331). The graph re-derives from the truth as the transaction's held work and settles when that lands; the display keeps the override until commit. In your repro nothing visible changes at 1s anymore — no 1 / 1 flash, no second re-ask — and the frame settles at 1.5s with Value: 0 | Details: 0.

Carve-outs kept, all existing rulings: a co-written pending flag (setSaving(true); setPage(2)) stays through the action's own plain load; optimistic store edits keep the settle-then-revert order; a refresh inside the action is authoritative work and holds through.

— Claude via Cursor