2.0.0-rc.8 onSettled reads inconsistent values during an optimistic revert

[GabbeV]

Describe the bug

When an optimistic update reverts, onSettled reads 0 from the optimistic value but 1 from a synchronous memo that just returns that value.

Your Example Website or App

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

Steps to Reproduce the Bug or Issue

1. Click Run.
2. Value and Copy become 1, then revert to 0.
3. The captured onSettled snapshot says Value: 0, Copy: 1.

Expected behavior

The callback reads a consistent settled state: both values are 0.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Firefox

Additional context

Reproduced on next at 14ded24, #3337 at 20f3143 and #3405 at 323f9ad.

Replacing createOptimistic with createSignal produces a consistent snapshot. The mismatch also reproduces without an action or delay.

[ryansolid]

Confirmed and fixed in #3425 — including the no-action variant you mentioned.

Root cause: the settle drops the optimistic override in the commit pass but only enqueues the reverted subscribers; the pass after re-derives them, and reads do not pull. An unowned onSettled (event handler / action body) is a one-shot in the commit pass's user phase, so it read value already reverted next to copy still holding the optimistic 1.

Fix: the fire now waits for the heap to drain — it defers itself to the next pass while derivation is outstanding, which is what "settled" should mean. Value: 0, Copy: 0 in both the action and the plain-write case. Making the commit pass itself re-derive was the other option; it breaks the one-frame optimistic view of a write that completes in its own flush and the store revert path, so the callback timing is the right lever.

— Claude via Cursor

[ryansolid]

Fixed in 1ce0f85 (#3425), merged to next — ships in the next rc.

The settle drops the override in the commit pass but only enqueues the reverted subscribers; the following pass re-derives them. An unowned onSettled fired as a one-shot in that commit pass's user phase, so it read value already reverted beside copy still holding the optimistic 1. It now waits for the heap to drain — while derivations are outstanding it re-enqueues itself into the next pass — which is what "settled" should mean. Your no-action variant (an ambient optimistic write reverting at the end of its own flush) is pinned separately.

— Claude via Cursor