Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
  • ¿Algo no está bien?
#3,962 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
18/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, typescript
Área
frontend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)

Lenguaje dominante
TypeScript
Estrellas
36.1k
Forks
1.1k
Merge medio
10 h 44 min
PR fusionados (30 d)
339

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de solidjs/solid

Todos los issues de solidjs/solid

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.