Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#4,071 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
12/100
Issue 类型
缺陷
描述清晰度
需要澄清
活跃度
活跃
技术栈
javascript, typescript
领域
frontend

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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 (#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

主要语言
TypeScript
星标
36.1k
派生
1.1k
平均合并
11 小时 45 分钟
30 天内合并 PR
329

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

solidjs/solid 的其他 Issue

查看 solidjs/solid 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。