Memoized sum disagrees with its async inputs during overlapping updates

[GabbeV]

Describe the bug

Two async memos feed a synchronous sum memo. Updating their inputs 500ms apart makes A display 1 while B and Sum both display 0.

Replacing the sum memo with a plain getter removes the mismatch.

Your Example Website or App

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

Steps to Reproduce the Bug or Issue

1. Wait for initialization.
2. Click Run.
3. After one second, A becomes 1 while B and Sum remain 0.
4. After another 500ms, B becomes 1 and Sum becomes 2.

Expected behavior

Sum should equal the displayed A + B throughout the update.

Screenshots or Videos

No response

Platform

Verified with compiled JSX in jsdom on Node.js 24.18.0, in development and production builds.

Additional context

Reproduced on next at c452850, #3439 at c2c9789 and #3337 at 20f3143.

Both updates use ordinary signals. No isPending reads, conditional dependencies or observer changes are involved.

Writing both inputs in the same event, without the await between them, removes the mismatch.

[ryansolid]

Confirmed at the core level and fixed in #3450 — thanks for the reduction, the "plain getter removes it" and "same event removes it" notes pointed straight at the mechanism.

Root cause: setB's flight only propagates pending onto sum (no recompute — its inputs' values are unchanged), so the memo's stamped re-entry, which is normally how two transactions sharing a memo become one, never ran. sum's reader registered on b in the second transaction, the first transaction's verdict at a's landing saw only its own reporters, and it revealed A: 1 beside the committed Sum: 0. The propagation now enters the held memo's transaction: one reveal, 3500: A: 1 | B: 1 | Sum: 2. A plain getter in the JSX stays parallel by design (effects don't entangle), which is why that variant showed a coherent Sum: 1 at 3000.

— Claude via Cursor

[ryansolid]

Fixed on next in 05c7e21 via #3450.

Root cause: setB opened a second transaction and b's pending propagated onto sum — a memo the first transaction still held — without recomputing it (its inputs' values were unchanged), so the memo's stamped re-entry never ran and the first transaction never learned it was waiting on b. Its verdict at a's landing saw only its own reporters, committed, and revealed A: 1 beside the committed Sum: 0.

Fix: notifyStatus's dependent walk, on a pending propagation reaching a memo another live transaction holds (pending on its work or carrying its staged value — the stamp alone decides nothing, so a write that supersedes a prior flight through a shared memo is not dragged into it), enters that transaction. The two flights settle as one unit (A15: a shared derivation of both): 3500: A: 1 | B: 1 | Sum: 2. Effects still entangle nothing by themselves, so the plain-getter shape stays parallel.

One consequence to be aware of: a write whose async work flows into a held memo is now held with it — page=1 waits with count=1 while details re-asks — even where a plain binding of the same write would pass through. That is pinned in tests/overlapping-flights.test.ts alongside the issue shape and the effect-arm control.

— Claude via Cursor