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

[2.0 rc.14] Projection rejection after a source change still never reaches `Errored` when the error is thrown synchronously on a version-bumped rerun (follow-up to #3887)

Cerrado
  • ¿Algo no está bien?
#3,956 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
22/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, typescript
Área
frontend

Línea de trabajo

Start by running the vitest reproduction in the issue with @solidjs/testing-library, which covers the key-change, version-bump, and synchronous-throw path. Compare behavior on rc.13 and rc.14, and check the commits a963ec1 and #3917 to see how the promise-rejection case was fixed. Done when the test shows ERRORED after the rejected rerun and the Loading fallback no longer hides the error. The second observation about the infinite loop has no repro and should be treated as separate work.

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

Descripción

Versions: solid-js / @solidjs/signals 2.0.0-rc.14 (regressed vs rc.13); also reproduced on next at 358159c (2026-10-09, includes a963ec1 / #3917 and #3954). Found through @tanstack/[email protected].

What happens

A createProjection changes its source key. The promise for the new key rejects. On rc.13 the nearest Errored boundary renders its fallback. On rc.14 the boundary never shows the fallback: the projection keeps the previous value, or the Loading fallback when there is no previous value.

#3887 described the same symptom and a963ec1 fixed the plain case, where the projection returns a promise and that promise rejects. The shape below is still broken on next. This is the shape @tanstack/solid-query v6 uses (useBaseQuery → computeData):

  1. the projection returns a promise while the query is pending;
  2. on settle, the external cache bumps a version signal that the projection reads;
  3. the rerun finds the entry in the error state and throws synchronously.

So the rejection reaches the projection as a synchronous throw on a rerun caused by the version bump, not as a rejected promise.

Reproduction (vitest + @solidjs/testing-library)

import { cleanup, render, screen } from "@solidjs/testing-library";
import { createProjection, createSignal, Errored, Loading } from "solid-js";
import { afterEach, expect, it } from "vitest";

afterEach(cleanup);
const settle = (ms: number) => new Promise((r) => setTimeout(r, ms));
const fetcher = (k: string) =>
  new Promise<{ items: string[] }>((res, rej) =>
    setTimeout(() => (k === "bad" ? rej(new Error("refused")) : res({ items: [`row-${k}`] })), 20),
  );

it("projection: rejection after a key change reaches Errored", async () => {
  const [key, setKey] = createSignal("good");
  const [version, setVersion] = createSignal(0, { ownedWrite: true });
  type E = { status: "pending" | "ok" | "error"; p: Promise<{ items: string[] }>; v?: { items: string[] }; e?: unknown };
  const cache = new Map<string, E>();
  const entry = (k: string) => {
    let e = cache.get(k);
    if (!e) {
      const ne: E = { status: "pending", p: fetcher(k) };
      ne.p.then(
        (v) => { ne.status = "ok"; ne.v = v; setVersion((x) => x + 1); },
        (err) => { ne.status = "error"; ne.e = err; setVersion((x) => x + 1); },
      );
      cache.set(k, ne);
      e = ne;
    }
    return e;
  };
  function Page() {
    const p = createProjection<{ value?: { items: string[] } }>(() => {
      version();
      const e = entry(key());
      if (e.status === "error") throw e.e;
      if (e.status === "ok") return { value: e.v! } as never;
      return e.p.then((v) => ({ value: v })) as never;
    }, {});
    return (
      <Errored fallback={() => <span>ERRORED</span>}>
        <Loading fallback={<span>PENDING</span>}>
          <span>{(p.value?.items ?? []).join(",")}</span>
        </Loading>
      </Errored>
    );
  }
  render(() => <Page />);
  expect(await screen.findByText("row-good")).toBeTruthy();
  setKey("bad");
  await settle(300);
  expect(document.body.textContent).toContain("ERRORED"); // rc.13: passes; rc.14 and next@358159c: still "row-good"
});

Expected: ERRORED, as on rc.13.
Actual (rc.14, next@358159c): still shows row-good.

Impact: with solid-query v6, opening entity A and then entity B whose request fails (e.g. 404) leaves the screen on A's data or on the loading state. The error is silently lost.

Separate observation (no minimal repro yet, reported only as an observation; looks related to #3945 but still reproduces on next@358159c, which includes #3954): on rc.14 we also see Potential Infinite Loop Detected. Kept alive by scheduled work; last staged node: computed (and … button.spread). In this case the mutation's transition never commits. It shows up when one element's spread reads both a mutation's in-flight flag (isPending, backed by createOptimistic inside an action) and a list that the same mutation invalidates and refetches. Removing any one of those reads makes it pass. Four smaller attempts at isolating it did not reproduce. Rolling back only @solidjs/signals to rc.13 makes it pass. We can share the failing app-level test if useful.

Lenguaje dominante
TypeScript
Estrellas
36.1k
Forks
1.1k
Merge medio
9 h 56 min
PR fusionados (30 d)
336

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.