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

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.

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:

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();
});

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)