Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
#4,071 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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:

  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

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

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của solidjs/solid

Tất cả issue của solidjs/solid

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.