signals: a landing reveals a held write its stale reader re-derives onto a new flight (U-5, D-9) #4071

What happens

A hold lands and publishes a held write while a render effect it was waiting on is about to discover a new flight. The screen tears: the write shows next to a reader that can only show its old frame.

Pin: packages/signals/tests/fuzz-findings-l2.test.ts, F2 (it.fails). Rule: D-9, the A15 reveal corollary ("a reveal that discovers a flight waits for it").

const [show, setShow] = createSignal(true);
const [src, setSrc] = createSignal(0);
const m0 = createMemo(() => fetchFor(src()));   // async
const m1 = createMemo(() => m0());
createRenderEffect(() => (show() ? [src(), m1()] : "hidden"), v => (panel = v));
createRenderEffect(show, v => (shown = v));

setShow(false); setSrc(1); // flight(1), unobserved: commits
setShow(true);             // panel would read m1 (pending): the reveal holds show=true
setSrc(0);                 // supersedes flight(1)
// today: shown=true, panel="hidden", flight(0) still in the air

Why

Traced on next @ 2da0f8e:

1. After setShow(true), the hold's nodes are show and the panel. The panel is a pending render effect, which is what blocks the hold (blocked, core/scheduler.ts).
2. setSrc(0) re-runs the panel on the main line (rule 3: a render effect re-run outside its transaction publishes mainline). It is served the committed show=false, returns "hidden", and its pending flag clears. It becomes a stale reader (REACTIVE_FRAME_READ).
3. The hold now has no pending reader, so it lands and releases shown=true.
4. Only then do the landing's reruns re-derive the panel in the landed world. It reads m1, finds flight(0), and goes pending in a new hold, too late.

The stale reader's re-derivation runs after the landing has decided.

Prototype and why it was not merged

Branch fix/landing-stale-reader-u5 (one commit): before a hold lands, re-derive the render effects it held that a mainline pass turned into stale readers, in the hold's own world (rederived in the landing loop). If one goes pending, the hold stays parked.

• F2 passes. The rest of fuzz-findings-l2 is green.

• Size: the change is in the core seam. Signals core floor +179 B minified (20,428 → 20,607, brotli 7,523 against a 7,480 cap). Render + one signal goes to 10,013 B brotli, past 10 KB.

• Two pinned orders break:

  • nested-render-effect-async-cleanup.test.ts (2.0.0-rc nested render effect cleanup run too early #3404): the old frame's cleanup now runs before the new frame's first run.
  • loading-value.test.ts, seeded projection refetch: v1 is applied twice.

  Fixing either needs more seam code.

An alternative is to let the landing commit, but move its effect runs onto the new hold when a re-derivation goes pending. That is also core code.

Deferred: the floors are frozen at 0 B, and this sits on the path every app pays for. A fix probably belongs with a broader rework of how holds track their stale readers.

Generated by Claude Code