[2.0 / next] Recovering before a held error commits throws the successful value
メンテナーはふだん 1 日以内に返信
評価
- 難易度
- 4/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 48/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- javascript, typescript
- 領域
- backend, testing-qa
調査の方向性
Start with the held-frame error handling described in the issue, especially stageError, _pendingValue, CONFIG_STAGED_ERROR, serve, and commitPendingNode. Read the related S-43 case in error-is-an-answer.test.ts and compare its recovery timing with this reproduction, which recovers before the error commits. Done means the successful value replaces the proposed error and the request can finish with the UI showing Sum: 3 without [REACTIVITY_HALTED].
索引モデルが issue の本文から書いたものです。
説明
Describe the bug
A memo throws while an async sibling keeps the rendered update held. Before the request finishes, the memo recomputes successfully. When the request then resolves, Solid throws the successful recovery value as an error, reports [REACTIVITY_HALTED], and leaves the old content on screen.
Your Example Website or App
https://s.olid.uk/id/df_wYAiPRlmgfLmezgxTag
Steps to Reproduce the Bug or Issue
Click each button once, in order; rebuild or reload to repeat.
- Initially the page shows
Sum: 2: both memos return1. - Click 1. Start update.
slowbecomes pending andvaluethrowsError("boom"). The previous sum stays visible. - Click 2. Recover.
valuesuccessfully returns1while the request is still pending. - Click 3. Finish request. The request resolves to
2. - The page stays at
Sum: 2. The console reports[REACTIVITY_HALTED]with the successful value 1 as the error.
Control: remove if (step() === 1) throw new Error("boom"); and rebuild. The same clicks produce Sum: 3.
Changing the recovery value to 7 makes Solid throw 7 instead; the sum stays 2 instead of becoming 9.
Expected behavior
The successful recomputation should replace the proposed error. Once the request resolves, the page should show Sum: 3 without throwing the recovered value or halting reactivity.
Screenshots or Videos
No response
Platform
- OS: Linux
- Browser: Chromium 154.0.8037.57
- Solid: playground pinned to
next@d2ad8b288886a5c7171e6746ccc019ad1d08d8ab, also the currentnexthead when checked on 2026-10-19. Reproduces with development and production builds.
Additional context
Follow-up to the error-outcome audit in #3886, which was closed in favor of the D-41 implementation in #4085. The related S-43 test in error-is-an-answer.test.ts covers recovery after the previous error has committed. This case replaces an error proposal with a successful value before that error commits, while the same frame is still held.
Related reports, with different triggers:
- #4109 concerns ordinary outside reads throwing before a held frame reveals. This repro fails during the eventual reveal, after the memo has recovered.
- #4110 concerns a direct write to a failed writable memo. This repro uses successful recomputation of an ordinary memo; there is no writable memo setter.
- #4106 was fixed by #4129 for error/value publication through
latest()derivations. This repro uses nolatest()and still fails on a commit containing that fix.
Likely cause: stageError stores the proposed error in _pendingValue and sets CONFIG_STAGED_ERROR. The successful recomputation replaces _pendingValue with 1 but leaves that flag set. A subsequent tracked read in serve therefore throws the successful value. The flag is normally cleared by commitPendingNode, after the failing read in this schedule.
The component uses one signal, two memos, a native Promise and ordinary JSX, with no timers or explicit effects/flushes. Source-level controls reproduce both same-value and changed-value recovery failures with immediate and native delivery; the no-error controls succeed.
- 主要言語
- TypeScript
- スター
- 36.1k
- フォーク
- 1.1k
- 平均マージ
- 11時間 45分
- マージ済み PR（30日）
- 329
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
solidjs/solid のほかの issue
-
CHEATSHEET.md and RFC 02 still recommend module-scope state for app-wide state (follow-up to #3390)オープン
難易度 1/5 1〜3時間 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信
-
`lazy()`: remounting an already-loaded component renders empty (or the Suspense fallback) since 1.9.14対応中かも @itisrmk が 2 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 42/100
メンテナーはふだん 1 日以内に返信
-
rc.14: inside an action, a non-keyed `<Show>`'s child memo re-runs after its condition turned falsy, and the stale-value throw halts reactivity対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 47/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
[测试] 等待仓库加载后再记录多仓库排序基线対応中かも @myot233 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
area:arcade p3-medium ready-for-agent testing type:docs
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
fderuiter/deruiter.dev#2369 ·
メンテナーはふだん 1 日以内に返信
-
area:devenv origin:agent type:bug
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
overengineeringstudio/effect-utils#1949 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
ccch1mneyyy/dsh-TUI#1631 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
MiniMax-AI/minimax-code#507 ·
メンテナーはふだん 1 日以内に返信