[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) #3956

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/solid-query@6.0.0-rc.5.

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.