2.0.0-rc.8 conditional memo reveals a held signal value early

[GabbeV]

Describe the bug

A conditional memo starts reading a signal while its update is held by an async memo. Panel shows 1 while Count and Details still show 0.

Your Example Website or App

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

Steps to Reproduce the Bug or Issue

1. Wait for initialization.
2. Click Run.
3. Panel becomes 1 while Count and Details still show 0.

Expected behavior

Panel and Count should agree whenever Panel is visible.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Firefox

Additional context

Replacing createMemo(() => show() ? count() : "hidden") with a plain getter removes the mismatch.

Possibly related to the held-input reveal rules discussed in #3334/#3370.

Reproduced on next at 14ded24 and #3405 at 323f9ad, in development and production.

[ryansolid]

Confirmed and fixed in #3431 — thanks for the reduction.

Root cause: readers that aren't stale are served a transaction's staged value (readers keep speculation — intended), but only writes and stamped recomputes entered the transaction that owns that value. A memo whose branch flipped mainline and started reading the held count got the staged 1 without joining the hold, so it published Panel: 1 next to Count: 0.

Rule added: a tracked computation served a live transaction's staged value enters that transaction, so its result is held with it — the read twin of the existing write-side entry. Your scenario now reveals Count: 1 | Details: 1 | Panel: 1 in one frame at the landing.

— Claude via Cursor