Reading a visible optimistic value in Show holds an independent signal update

[GabbeV]

Describe the bug

A synchronous signal write remains pending when a <Show> condition reads that signal alongside an already-visible optimistic value. The two writes occur in separate tasks:

const [optimistic, setOptimistic] = createOptimistic(false);
const [drag, setDrag] = createSignal(false);

const move = action(function* () {
  setOptimistic(true);
  yield new Promise<void>(() => {});
});

void move();
setTimeout(() => setDrag(true), 0);

<Show when={optimistic() && !drag()} keyed>
  <p>Optimistic content</p>
</Show>

After the timeout runs, optimistic() is visibly true, but drag() is still false, latest(drag) is true, and isPending(drag) is true. The independent signal update is held by the unfinished action even though the condition has a visible optimistic value to read.

Your Example Website or App

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

Steps to Reproduce the Bug or Issue

1. Open the example and click Run reproduction once.
2. Observe optimistic: true, drag: false, latest(drag): true, and isPending(drag): true.

Expected behavior

The separate synchronous signal write should publish immediately: drag() should be true, isPending(drag) should be false, and the optimistic content should disappear while the action remains open.

Platform

• OS: Linux
• Browser: Chromium 153.0.8010.12 (Playwright)
• Solid: 2.0.0-rc.11 (next in the linked playground)

[ryansolid]

Reproduced, and the fix is up in #3703 — thanks for the precise reduction.

Your read of the model is right: an optimistic write opens a lane, a reader of the override is a lane member (it displays now and is promoted or reverted with the action), and lane membership is not transaction membership. Per the #3460 ruling, a lane never holds a synchronous write — so setDrag(true) should have published on the plain channel and isPending(drag) should have stayed false.

What actually held it was narrower than a rule problem. A bare createMemo(() => optimistic() && !drag()) behaves correctly on next. <Show> reproduces because the compiler emits a child memo (_$memo(() => !!optimistic())) inside the when getter, so the condition memo owns children. When the lane pass recomputed that memo, its previous children were parked as a transaction zombie (#3404) — the lane-frame treatment from #3662 had only been applied to effects. Owning a parked zombie made the memo a pending node of the action and stamped it with the transaction, and on the next mainline recompute (setDrag) the stamped memo re-entered the hold, dragging the batch with it.

The change is the parking gate in recompute: a memo's lane pass now parks a lane frame like an effect's does, retired when the lane applies rather than at the action's commit. Pinned with your shape (both keyed and non-keyed Show, plus the primitive equivalent with revert and confirm paths) and a contrast test showing that a reader served superseded truth still enters the transaction as intended.

— Claude via Cursor

[ryansolid]

Merged to next in #3703 (6958367) — thanks for the precise reduction. The same root cause and fix were found independently by @brenelz in #3699, who is co-author on the landed commit.

The ruling this lands under: a pass is lane work or transaction work by who owns it, not by the kind of node it runs on — a lane pass over a memo parks a lane frame exactly as one over an effect does, and lane work never makes its node transaction work, so setDrag(true) publishes at once while the action stays open (drag() true, isPending(drag) false).

Ships in the next RC. Closing by hand since next is not the default branch.

— Claude via Cursor