signals: a landing reveals a held write its stale reader re-derives onto a new flight (U-5, D-9)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 12/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- javascript, typescript
- Lĩnh vực
- frontend
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- TypeScript
- Star
- 36.1k
- Fork
- 1.1k
- Merge trung bình
- 11 giờ 49 phút
- Pull request đã merge (30 ngày)
- 346
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của solidjs/solid
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 18/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 Nửa ngày Mức phù hợp với người mới 55/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[2.0 / next] Error formatting and async iterator protocol failures escape memo error handlingĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 22/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 14/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của solidjs/solid
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 83/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
ranxianglei/billion-context#3583 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug:new
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
callstackincubator/simlock#673 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation v3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
anomalyco/opencode#56380 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày