2.0.0-rc.8 conditional memo disagrees with its inputs during a held branch change

[GabbeV]

Describe the bug

selected = createMemo(() => fixed() ? 2 : count()) shows 0 while Fixed is false and Count is 1. With those inputs, Selected should be 1.

Your Example Website or App

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

Steps to Reproduce the Bug or Issue

1. Wait for initialization.
2. Click Run.
3. Count becomes 1 while Fixed remains false and Selected remains 0.

Expected behavior

Selected should equal Count while Fixed is false.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Firefox

Additional context

The async details memo holds the branch change. Updating Count during that hold exposes the mismatch. Keeping Count as an unconditional dependency removes it.

Reproduced on next at 14ded24. The earlier equivalent repro also reproduces on #3337 at 20f3143 and #3405 at 323f9ad.

[ryansolid]

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

Root cause: selected's held pass (fixed → true) stopped reading count, and the engine trimmed the count edge right there — even though selected's committed value (0) still derived from count. So setCount(1) never reached it and Count: 1 rendered beside Selected: 0 while Fixed still read false.

Rule added: a memo's dependencies are the committed frame's until that frame is replaced. A pass that stages its value leaves the previous pass's dependency tail linked and the commit trims it. The count write then dirties the stamped memo, which joins the hold — exactly what an unconditional count() read would do. Your scenario now reveals Count: 1 | Details: 2 | Fixed: true | Selected: 2 in one frame at the landing.

— Claude via Cursor

[ryansolid]

Fixed in c3ae310 (#3431), merged to next — ships in the next rc.

setFixed(true) was held. selected's held pass stopped reading count, and the dependency trim dropped that edge immediately — so setCount(1) never reached a memo whose committed value still derived from count: Count: 1 beside Selected: 0 / Fixed: false. Keeping count unconditional avoided it because the edge survived and the write entangled with the hold.

Rule now (A30): a memo's dependencies are the committed frame's until the frame is replaced. A pass that stages its value leaves the previous pass's dependency tail linked, and the commit trims it. A write to a source the committed value still derives from reaches the memo and joins the hold — exactly as the unconditional read does. Your repro holds Fixed: false | Count: 0 | Selected: 0 through the hold and reveals Fixed: true | Count: 1 | Selected: 2 | Details: 2 together at the landing.

— Claude via Cursor