Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#4,332 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
javascript, typescript, vite
領域
backend, frontend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
36.2k
フォーク
1.1k
平均マージ
10時間 28分
マージ済み PR（30日）
379

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

solidjs/solid のほかの issue

solidjs/solid の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。