2.0.0-rc Loading reveals stale content before downstream async work finishes

[GabbeV]

Describe the bug

After two updates to a Loading boundary's on value, it leaves its fallback before the new details are ready. The repro shows Details: 0 → Loading... → Details: 0 → Details: 3. The second 0 is stale: the displayed sum is already 3.

Your Example Website or App

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

Steps to Reproduce the Bug or Issue

1. Wait for Sum and Details to show 0.
2. Click Run.
3. Loading disappears and the old Details: 0 returns for two seconds before Details: 3 arrives.

Expected behavior

Keep the loading fallback until the new details are ready, then show Details: 3.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Firefox

Additional context

Reproduces on next at f8b40b7 (development and production) and #3337 at 20f3143.

Removing either setCount(1) or the second page update prevents the stale reveal.

[ryansolid]

Reproduced at the signals level and fixed in #3381. Two things were wrong, both surfaced by the second on change.

1. Boundary collection. The on reset clears the boundary's collected sources and rebuilds them from later notifications. Status propagation dedupes on what the effect already carries, so details — which the effect had been pending on since the count write — was never re-reported after the reset, and details' re-flight after pageData landed stayed invisible. When pageData settled the boundary had nothing left to wait on and revealed with the effect still pending. A collecting boundary now records every source the notifying effect is pending on.
2. Transaction completion. The transaction decided "this source's own flight is still up" by _error.source === source, which a later-pending input overwrites on propagation — details was still flying but read as settled, so the count=1 hold committed at 5500, ahead of its answer. The test is now the source's self entry in its pending sources.

Your timeline now shows the fallback from the first page change through details' final landing, then Details: 3 — no stale reveal. One thing to be aware of: page=2 now rides the count hold and reveals at 8500 too (pageData, a reader of page, joined the hold when its earlier landing entered it — A15). Before the fix that hold was leaking early through the _error.source bug. Whether an on reset should release the page write instead is a spec question flagged on the PR.

— Claude via Cursor

[ryansolid]

Follow-up on the Sum timing: with a82d2e3 on #3381, the page writes are no longer held behind details once the boundary shows its fallback. Ruling: a boundary's on reset ends the hold on writes that only its readers observed; a reader outside the boundary still holds. Your sequence now goes Details: 0 → Loading... (Sum updates as you click) → Details: 3, with no stale Details: 0 in between.

— Claude via Cursor

[ryansolid]

Fixed on next in d7cb456 (#3381). Two mechanisms: a collecting Loading boundary only recorded the source carried by each notification (status propagation dedupes, so details' re-flight after the on reset was invisible and the boundary revealed on pageData alone); and transitionComplete tested "own flight up" via _error.source, which a later-pending input overwrites, so the still-flying details read as settled. A collecting boundary now records every source the effect is pending on, and the completion test is the node's own entry.

One ruling landed alongside (2026-09-12): a Loading boundary's on reset ends the hold on writes that only its readers observed — a reader behind the fallback no longer blocks; a reader outside the boundary still does. In your timeline page=2 rides the count hold (Sum: 3 at 8500) because pageData is a reader of page living in that hold — that is A15 applying, where before it leaked early through the _error.source glitch.

— Claude via Cursor