signals: a landing reveals a held write its stale reader re-derives onto a new flight (U-5, D-9)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 12/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Active
- Tech stack
- javascript, typescript
- Domain
- frontend
Research direction
The failing case is F2 in packages/signals/tests/fuzz-findings-l2.test.ts, marked it.fails; the hold logic is in core/scheduler.ts (blocked) and the landing loop. The issue says the candidate fix breaks nested-render-effect-async-cleanup.test.ts and loading-value.test.ts, and the size floors are frozen, so a newcomer would first need the maintainers' decision on approach. Done means F2 passes without breaking those pinned orders or the bundle caps.
Written by the indexing model from the issue text.
Description
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:
- After
setShow(true), the hold's nodes areshowand the panel. The panel is a pending render effect, which is what blocks the hold (blocked, core/scheduler.ts). 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 committedshow=false, returns"hidden", and its pending flag clears. It becomes a stale reader (REACTIVE_FRAME_READ).- The hold now has no pending reader, so it lands and releases
shown=true. - Only then do the landing's
rerunsre-derive the panel in the landed world. It readsm1, 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-l2is 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(#3404): the old frame's cleanup now runs before the new frame's first run.loading-value.test.ts, seeded projection refetch:v1is 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
- Dominant language
- TypeScript
- Stars
- 36.1k
- Forks
- 1.1k
- Avg merge
- 11h 37m
- Merged PRs (30d)
- 344
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from solidjs/solid
-
`lazy()`: remounting an already-loaded component renders empty (or the Suspense fallback) since 1.9.14Possibly taken @itisrmk claimed this 3 days ago. Open1.x
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 51/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 1-2 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
`createRoot`'s dispose function keeps `fn` alive, so `<For>`/`<Index>` rows retain removed list itemsPossibly taken @boombang claimed this 5 days ago. Open1.x
Difficulty 4/5 1-2 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
Similar issues
-
area: app type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
ExpidetGames/code-reviewer#585 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 83/100
module-federation/core#5205 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
LanternOps/breeze#9392 · 1 comment ·
Maintainers usually reply within 1 day
-
engine-rs P3 review-deferral wasm
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
maniator/verticopolis#1154 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day