2.0.0-rc.8 shared render effect entangles a synchronous action with an unrelated pending update

[GabbeV]

Describe the bug

A synchronous action gets held by an unrelated pending update when both are read in the same render effect.

Splitting the expression into separate JSX holes, or calling setB directly instead of through action, removes the wait.

Your Example Website or App

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

Steps to Reproduce the Bug or Issue

1. Click Start.
2. B is set after 500ms, but the output stays at 0:0 until becoming 1:1 at 2 seconds.
3. Replace the paragraph with <p>{b()}:{detailsA()}</p> and rerun. It now shows 1:0 at 500ms.

Expected behavior

B should publish at 500ms, showing 1:0, then 1:1 when A finishes. Sharing a render effect should not entangle the updates.

Screenshots or Videos

No response

Platform

• OS: [e.g. macOS, Windows, Linux]
• Browser: [e.g. Chrome, Safari, Firefox]
• Version: [e.g. 91.1]

Additional context

Possibly related to #3322.

The merge happens when recompute re-enters the shared effect's _transition while another transition is active. Excluding effects from that re-entry fixes this repro, but breaks existing reveal-completion tests, including cases covered by #3305/#3334. Those suspended reveals still need to resume correctly.

[ryansolid]

Confirmed and fixed in #3434 — thanks for the plain-vs-action contrast, it pointed straight at the cause.

Root cause: recompute re-entered a stamped effect's transaction whenever any other transaction was active — at the head of the pass, before anything could have been observed. The counter's render effect was stamped by the held detailsA flight, so the action's sync write merged into that flight's transaction and waited; the plain write had no transaction to merge and passed through.

Rule now: a render effect's pass belongs to whatever dirtied it. The stamp re-entry is memo-only (a memo's value is its transaction's work); an effect dirtied by another writer runs that writer's pass, reads the held flight as a stale reader (its committed value, coherent with the flight's still-committed inputs) and publishes with the writer. Only a pass that actually observes a flight pending joins it. The compiler's grouping of bindings into one effect is never a reason for one binding to hold another. Both variants of your repro now publish 1:0 at the write and 2:1 at the landing.

— Claude via Cursor

[ryansolid]

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

The wait came from recompute's head: a render effect stamped by the async transaction (it had read detailsA pending) re-entered that transaction whenever any other transaction was active — before the pass ran, before anything could have been observed. Your action write to b dirtied the shared effect, the head folded the action's transaction into the async's, and b waited with detailsA. Separate holes never shared a stamp, and a plain setB had no transaction to fold, which is why both variants published 1:0.

Rule now (A15 shared-hole corollary): a render effect's pass belongs to whatever dirtied it. The stamp re-entry is memo-only — a memo's value is its transaction's work — while a stamped effect dirtied by another writer runs that writer's pass, reads the held flight as a stale reader (committed value, coherent with the flight's committed inputs) and publishes with the writer. Only a pass that actually observes a pending flight joins it. Your case now shows 0:0 → 1:0 at 500ms → 1:1 when A lands; pinned plain-vs-action in shared-effect-no-entangle.test.ts.

— Claude via Cursor