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

[next] After #3954, a reader re-queued by a derived store's rejection sees the errored store as settled

Đã đóng
  • Có gì không ổn?
#3,962 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ó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
18/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
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 regression comes from commit 0c709076, where errorFamily marks re-queued readers with _errorMeet and pullFamily then drops STATUS_ERROR from the mask. Start with the reproduction test, which uses createStore, isPending, createErrorBoundary and flush, and confirm that the isPending probe reports true after the second page rejects. Done means the probe stays false after the rejection and the errored store still throws, with the signals, solid and rc.14 comparison suites passing.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

0c709076 (#3954, fixing #3945) marks every reader that errorFamily re-queues with _errorMeet, and pullFamily then drops STATUS_ERROR from its mask for that reader, taking the untracked pull. Inside an isPending(...) probe that pull neither throws the stored error nor reports pending. So a "has this store settled?" probe that re-runs because of the rejection reports settled, over the previous page's rows, while the store is errored.

The same probe in a reader created after the rejection, against the same store, still meets the error (A16: a thunk that throws a real error yields "not pending"), and the commit's own comment says a re-queued reader "throws the stored error". So the answer depends on whether the reader happened to be subscribed when the rejection landed:

Reader of the errored store, same probe next 358159c6 2.0.0-rc.14
created after the rejection not settled (read throws) not settled
subscribed before, re-queued by the rejection settled, with page 1's rows not settled

Reproduces on next at 358159c6. Passes on 2.0.0-rc.14 (no #3945 fix) and with the narrower fix proposed in #3945 in place of 0c709076's source change.

Reproduction (signals only)
it("a reader re-queued by a derived store's rejection does not see it as settled", async () => {
  const inflight: PromiseWithResolvers<{ items: string[] }>[] = [];
  const [page, setPage] = createSignal(1);
  const [todos] = createStore(
    async () => {
      page();
      const d = Promise.withResolvers<{ items: string[] }>();
      inflight.push(d);
      return d.promise;
    },
    { items: [] as string[] }
  );
  const settled: boolean[] = [];
  const dispose = createRoot(d => {
    // "Has the store settled content?" — read inside isPending.
    createEffect(
      () => {
        let read = false;
        const pending = isPending(() => {
          void todos.items;
          read = true;
        });
        return !pending && read;
      },
      v => {
        settled.push(v);
      }
    );
    // The rows, behind an error boundary.
    const rows = createErrorBoundary(
      () => todos.items.join(","),
      () => "error"
    );
    createRenderEffect(rows, () => {});
    return d;
  });

  flush();
  inflight[0].resolve({ items: ["page 1"] });
  await drain(); // six rounds of setTimeout(0) + flush()
  expect(settled.at(-1)).toBe(true);

  setPage(2);
  flush();
  await drain();
  expect(settled.at(-1)).toBe(false);
  const before = settled.length;
  inflight[1].reject(new Error("page 2 unavailable"));
  await drain();
  // Page 2 has no content: the store is errored, not settled with page 1's.
  expect(settled.slice(before)).not.toContain(true); // next: [true]
  dispose();
});
Build Result
next 358159c6 fails: the probe reports true after the rejection
next with 0c709076's source change replaced by the #3945 proposal passes
2.0.0-rc.14 passes

Without the error-boundary reader the probe is not re-queued, and the test passes on next too.

What we observed

A paginated source attaches live updates only once its probe says the store has settled content, and records the rows it attaches (with their versions). After a rejected page, the probe reported settled, so the previous page's rows were recorded under the new page. A Retry (refresh then reset) then resolved with the requested page, whose row had the same id and version, and the recorded stale row won: the screen kept the previous page. Separately, a pending view's conditional <Show> that re-reads an errored source in a later cycle no longer retries it (2 reads instead of 3), presumably the same sticky mark. Neither happens on rc.14 or with the #3945 proposal.

Note

The mark is never cleared, so it also outlives the rejection that set it. Scoping it to that rejection's own flush, or clearing it when the family next lands, may keep #3945's no-refetch guarantee without changing what a later probe sees. For comparison, the #3945 proposal passes upstream's #3945 test and the signals (5,123), solid (854) and web suites; in one synthetic shape (a kept keyed row reading a field plus isPending, retried with refresh then reset) it makes one extra read where 0c709076 makes none.

(submitted by Claude Opus 5.5 on behalf of rvlzzr)

Ngôn ngữ chính
TypeScript
Star
36.1k
Fork
1.1k
Merge trung bình
9 giờ 56 phút
Pull request đã merge (30 ngày)
336

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.