2.0.0-rc.7 render effect depending on non async values from two concurrent updates commit with the wrong data

[GabbeV]

Describe the bug

When a render effect depend on two sync values held back by two non entangled updates the updates trample each other losing one of the updates and committing the other at the wrong time.

Your Example Website or App

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

Steps to Reproduce the Bug or Issue

1. Open repro
2. Click button
3. Observe that the combined b increments when a commit and the combined a never increment

Expected behavior

A increment when a commit and b increment when b commit just like in the separate jsx hole version.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Firefox

Additional context

No response

[GabbeV]

Result from AI bisect:

It’s a regression introduced in beta.11.

• beta.10: stays consistent, publishing both together.
• beta.11–beta.34 and rc.0–rc.7: all reproduce the incorrect 0:1 and subsequent stale display.
• Commit bisect identified 7d4d0c3a — “perf(signals): optimize synchronous scheduler paths”. Its immediate parent passes.
  Specifically, its needsPendingCommit guard skips queue entries that also carry transition bookkeeping. Removing just that guard fixes this repro, both at the original commit and current clean next; restoring it brings the failure back.
  The npm boundary also holds with the actual timed component in jsdom, in development and production builds. Our prototype remains untouched.

[ryansolid]

Fixed on next in 1354a53a — thanks for the tight reproduction; it went in essentially verbatim as the first regression test.

Root cause: effects have one value slot and, unlike memos, do not entangle transactions (a shared effect is not shared state). With two non-entangled transactions in flight, the second one's recompute overwrote the value the first still owed a run for; the first's commit was silent (staging had already notified), so it published 0:1, and the second found nothing left to run. recompute now detects the owner change (Effect._valueTransition), records the effect on every owed live transaction, and each of those commits re-derives it against the committed world ahead of its effect phase — so the published value is always derived from what actually committed. The signal read fast path also gained the stale-reader mask for a foreign transaction's staged value that the slow path already applied.

Ships in rc.8.

— Claude via Cursor