Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue 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)

Chiusa
  • Qualcosa non va?
#3,956 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
22/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript, typescript
Ambito
frontend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
36.1k
Fork
1.1k
Merge medio
9h 56m
PR unite (30g)
336

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solidjs/solid

Tutte le issue di solidjs/solid

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.