signals: a landing reveals a held write its stale reader re-derives onto a new flight (U-5, D-9)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 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:
- 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
- 主要言語
- TypeScript
- スター
- 36.1k
- フォーク
- 1.1k
- 平均マージ
- 10時間 41分
- マージ済み PR（30日）
- 363
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
solidjs/solid のほかの issue
-
難易度 3/5 半日 初心者へのやさしさ 55/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 半日 初心者へのやさしさ 45/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
wormhole-foundation/wormhole#5062 ·
メンテナーはふだん 1 日以内に返信
-
internal os specific
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
frostney/GocciaScript#1688 ·
メンテナーはふだん 1 日以内に返信
-
integration:hermes
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
vectorize-io/hindsight#5592 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
vercel/streamdown#673 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
apache/rocketmq-dashboard#6712 ·
メンテナーはふだん 3 日以内に返信