Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[2.0 rc.14 / next] SSR: async memo retries run under another concurrent render's context

Chiusa
  • Qualcosa non va?
#3,972 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à
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
javascript, typescript
Ambito
frontend

Direzione di ricerca

The retry path is subscribePendingRetry → update → run in packages/solid/src/server/signals.ts; compare the captured ctx near lines 1257-1259 with run near lines 1314-1317, which restores the owner but not sharedConfig.context. Reproduce with the failing test in packages/web/test/server/repro-retry-render-context.spec.tsx (run under the server vitest config). Done when that test passes and the existing server suite still passes.

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

Descrizione

Describe the bug

On the server, an async createMemo that throws NotReadyError is retried when its source settles (subscribePendingRetry → update → run). run restores the memo's owner, but not its render context. The retry, and everything it creates, runs under whichever render last set sharedConfig.context. Under concurrent requests, that is often another request's.

The memo already captures its render's ctx at creation for exactly this reason (packages/solid/src/server/signals.ts:1257-1259: "async re-computations … may run after a concurrent request has overwritten sharedConfig.context"). However, run (signals.ts:1314-1317) never reinstates it.

createSyncMemo has no retry of its own: it re-runs when a reader pulls it, so it inherits its reader's context. That makes it affected whenever its reader is an async memo's retry, and the same fix covers it. The outer memo of children() is one.

An ordinary layout is enough to trigger it: a slot resolved with children(), gated by <Show when={slot() !== undefined}>, whose content waits on data. The Show's when memo is not ready, so it is retried later. The retry resolves the slot, which creates the slot's content under the other request's context.

Impact in a real app. This isn't only a context mismatch: under concurrent requests it can lock up the server. In a Solid 2 SSR app with this layout shape (a page component resolving an optional slot with children(), gated by <Show when={slot() !== undefined}>, whose content waits on data), a cold dev server receiving 18 page loads, 6 at a time, sometimes stops responding. The process sits at 100% CPU and most loads time out (13 of 18 in one run). Pages that do render can fail to hydrate the slot's content (Hydration key miss).

Sampling the stuck process shows the mechanism. The slot content created under the other render gets the same owner id as that render's own memo, so the two share one hydration slot and its deferred. When one memo settles it, the other's reader keeps re-subscribing to the already-settled promise in microtasks, and the event loop never gets a turn.

With the diff below applied to dist/server{,.dev}.js, 10 of 10 runs completed cleanly. Without it, 3 of 10 runs locked up.

Your Example Website or App

Server test on next (a497d4b1), for packages/web/test/server/:

/** @jsxImportSource @solidjs/web */
import { expect, test } from "vitest";
import { renderToStream } from "@solidjs/web";
import { children, createMemo, sharedConfig, Show, type JSX } from "solid-js";

const render = (code: () => any) =>
  renderToStream(code).pipeTo(new WritableStream({ write() {} }));

const later = <T,>(value: T, ms: number) => new Promise<T>(r => setTimeout(() => r(value), ms));

// A layout with an optional side slot: resolved once with `children()`, and laid
// out differently when it is present.
function Layout(props: { side?: JSX.Element }) {
  const side = children(() => props.side);
  return (
    <Show when={side() !== undefined} fallback={<main />}>
      <aside>{side()}</aside>
      <main />
    </Show>
  );
}

test("a slot resolved by children() is created under its own render's context", async () => {
  const contexts: Record<string, unknown> = {};
  const seenBy: Record<string, unknown> = {};

  // Two requests rendering the same page; each page's slot waits on its own data.
  const page = (name: string, ms: number) =>
    render(() => {
      contexts[name] = sharedConfig.context;
      const data = createMemo(() => later(name, ms));
      return (
        <Layout
          side={
            <Show when={data()}>
              {(() => {
                seenBy[name] = sharedConfig.context;
                return name;
              })()}
            </Show>
          }
        />
      );
    });

  await Promise.all([page("A", 5), page("B", 10)]);

  expect(seenBy.A).toBe(contexts.A);
  expect(seenBy.B).toBe(contexts.B);
});
Steps to Reproduce the Bug or Issue

In packages/web, run pnpm exec vitest run --config vite.config.server.mjs test/server/repro-retry-render-context.spec.tsx.

Expected behavior

Each page's slot content is created under its own render's context. Instead, page A's is created under page B's, and the test fails.

Restoring the captured context in run makes the test pass, and the existing server suite still passes:

   const run = () => {
     resetOwnerForRerun(owner);
-    return runWithOwner(owner, () => runWithObserver(comp, () => comp.compute(comp.value)));
+    const prevCtx = sharedConfig.context;
+    sharedConfig.context = ctx;
+    try {
+      return runWithOwner(owner, () => runWithObserver(comp, () => comp.compute(comp.value)));
+    } finally {
+      sharedConfig.context = prevCtx;
+    }
   };
Platform
  • solid-js / @solidjs/web: next @ a497d4b1, and 2.0.0-rc.14
  • Node 24.20, macOS
Lingua principale
TypeScript
Stelle
36.1k
Fork
1.1k
Merge medio
10h 44m
PR unite (30g)
339

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.