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

2.0 rc: subFetch swaps the global Promise during hydration; user-cached import() becomes a never-settling MockPromise

Aperta
  • Qualcosa non va?
#4,332 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
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
javascript, typescript, vite
Ambito
backend, frontend

Direzione di ricerca

Read dist/solid.js:422-429 to trace how subFetch swaps and restores the global Promise during hydration, and compare this with the fix for #4013 in #4019. Reproduce the cached import() case using the supplied example and verify whether a promise created during hydration remains pending after another component calls the cache. Done means the cached load resolves after hydration without breaking the existing lazy() and lazyModule() behavior.

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

Descrizione

Versions: solid-js 2.0.0-rc.18 (also present in 2.0.0-rc.19: dist/solid.js:429), @solidjs/web 2.0.0-rc.18, Vite 8.3.5.

Related: #4013, fixed by #4019 for lazy()/lazyModule(). This is the same root cause reaching user code that #4019 doesn't cover.

What happens

While hydration traces an adopted async computation, subFetch (dist/solid.js:422) sets the global Promise = MockPromise (:428) and window.fetch to return a MockPromise, runs the computation, then restores both. MockPromise's then/catch/finally/resolve/all return new mock promises that never settle.

Any user code that creates a promise during that window and keeps it gets a promise that never resolves. A common case is a module-level de-duplication cache for lazy imports. Vite's __vitePreload, which wraps every built import(), starts with let promise = Promise.resolve(), reading the global at call time, so the stored import() is a MockPromise.

Repro
// messages.js
const loads = new Map()
export function load(key) {
  let p = loads.get(key)
  if (!p) loads.set(key, (p = import("./catalog.js"))) // built: goes through __vitePreload
  return p
}

// component (SSR'd inside <Loading>, then hydrated)
const data = createMemo(() => load("x"))
  1. SSR the component inside <Loading> so the memo's value is serialized, then hydrate.
  2. During hydration the memo runs only to track reads, under subFetch, so load("x") stores a MockPromise in loads.
  3. Unmount, then mount another component that calls load("x").

Expected: it resolves with the module.
Actual: it stays pending forever. No request for catalog.js is made, and in an app this froze client navigation.

Suggested fix

Don't replace globals. Pass the mock explicitly where Solid needs it, or restore the globals before user code can create promises it keeps. At minimum, document that promises created inside a computation while it hydrates are fake and must not be cached.

Workaround

On the client, when the memo already holds the hydrated (serialized) value, write it into the cache, so later callers never touch the stored mock promise.

Lingua principale
TypeScript
Stelle
36.2k
Fork
1.1k
Merge medio
10h 57m
PR unite (30g)
360

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.