Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem 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)

Đã đóng
  • Có gì không ổn?
#3,956 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
22/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, typescript
Lĩnh vực
frontend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
36.1k
Fork
1.1k
Merge trung bình
10 giờ 41 phút
Pull request đã merge (30 ngày)
363

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của solidjs/solid

Tất cả issue của solidjs/solid

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.