Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#3,962 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
18/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, typescript
Domain
frontend

Research direction

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.

Written by the indexing model from the issue text.

Description

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)

Dominant language
TypeScript
Stars
36.1k
Forks
1.1k
Avg merge
11h 34m
Merged PRs (30d)
341

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from solidjs/solid

All issues in solidjs/solid

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.