Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#3,962 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
18/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript, typescript
領域
frontend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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)

主要言語
TypeScript
スター
36.1k
フォーク
1.1k
平均マージ
10時間 44分
マージ済み PR（30日）
339

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

solidjs/solid のほかの issue

solidjs/solid の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。