[2.0 / next] Recovering before a held error commits throws the successful value
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 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 小时 37 分钟
- 30 天内合并 PR
- 344
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
solidjs/solid 的其他 Issue
-
`lazy()`: remounting an already-loaded component renders empty (or the Suspense fallback) since 1.9.14可能已有人在做 @itisrmk 于 2 天前认领。 未关闭1.x
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
[2.0 rc.15 + next] For row lifecycle cleanup inherits the list computation and halts on a shared-state write可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 51/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
维护者通常 1 天内回复
-
`createRoot`'s dispose function keeps `fn` alive, so `<For>`/`<Index>` rows retain removed list items可能已有人在做 @boombang 于 4 天前认领。 未关闭1.x
难度 4/5 1-2 天 新手友好度 45/100
维护者通常 1 天内回复
-
signals: a landing reveals a held write its stale reader re-derives onto a new flight (U-5, D-9)未关闭
难度 5/5 一周以上 新手友好度 12/100
维护者通常 1 天内回复
相似的 Issue
-
docs(api): openapi.yaml still documents gif-tools optimize colors as 2-256 instead of 2, 4, 16, 256未关闭area: backend documentation priority: low
难度 2/5 1-3 小时 新手友好度 84/100
snapotter-hq/SnapOtter#2919 ·
维护者通常 1 天内回复
-
accepted :+1: bug db/redis
难度 2/5 1-3 小时 新手友好度 76/100
beekeeper-studio/beekeeper-studio#4882 · 1 条评论 ·
维护者通常 1 天内回复
-
ready-for-triage
难度 2/5 1-3 小时 新手友好度 72/100
konflux-ci/konflux-ui#1630 · 1 条评论 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 67/100
ahmedkhaleel2004/gitdiagram#233 ·
-
难度 2/5 1-3 小时 新手友好度 72/100
simkimsia/netlify-axi#19 ·
维护者通常 1 天内回复