Bug: Chat view freezes after loading earlier history — root cause found, fix branch ready

[northwang-lucky]

Symptom

In the Web UI, opening a long session and clicking Load earlier can freeze the Chat view:

• the prepended history never renders, yet the paging button disappears as if history were complete;
• the Turn-process fold control (N tool calls · M messages) appears, but toggling it only changes row spacing — member rows never hide.

Root cause

Traced with a live DOM inspection against the affected session:

1. After a prepend, replayDependencies replays request-prompt's start() because its predecessor resolution changed, flipping showsPrompt to false.
2. buildViewNode then returned null for an already materialized system-prompt node, tripping the assembler's materialized-target contract: conversation Definition "request-prompt" withdrew materialized target "chat" (visible in the browser console).
3. That throw aborts the whole projection flush, while the event window (including hasMore) had already committed — so every later flush re-throws on the same Context and the view stays frozen. The fold control's member hiding rides the same stuck projection, which is why only the store-driven chrome (chevron, spacing) still responded.

Fix

Ready on a fork branch: northwang-lucky:fix/chat-request-prompt-prepend-withdraw (commit 988368d6).

• request-prompt keeps a materialized node mounted with visibility: 'hidden' instead of withdrawing it (same precedent as assistant.ts).
• The assembler isolates per-Context failures in all four build loops: a throwing or withdrawing Definition is reported and skipped, previously published nodes and Location data are preserved, and siblings keep publishing. The withdrawal violation becomes a report (keeping the contract guidance) rather than a fatal throw.
• A full audit found request-prompt to be the only Definition with a withdraw-after-materialize path.
• Tests: the prepend-flip case for request-prompt, plus failure-isolation cases for both build paths and both Location-data paths; test:gui green, and the recorded-session web replay suite passes.

Happy to open this as a PR if a maintainer can enable that path for my account (CreatePullRequest is currently denied), or feel free to pick the branch directly.

Demo

Recorded from a real server booted from the fix branch, serving a byte copy of the affected session: history loads fully (turns 1–15 render) and the fold expands/collapses its member rows correctly.

[yamingmou]

EN / English

An outside research team — we use DSH daily — just confirming your fix direction has independent corroboration, since this thread has no comments yet.

Your diagnosis (withdraw after materialization → assembler throws → whole projection flush aborts → view freezes) is the same failure class we reported in #5692: the assembler treats one unexpected context transition as a fatal error instead of degrading. The fix direction you've implemented — report the withdrawal violation instead of throwing, and isolate the build-loop failure so one stuck context can't freeze later flushes — is exactly the degrade path we proposed for #5692 (log and skip the offending block; don't let a single bad context abort the window).

We just consolidated the family in a comment on #5884 (also more than one start Match, plus #5909's Mode B — same blank-view symptom, four different triggers: sequencing, lifecycle, id reuse, id duplication): one shared root = fatal-throw with no isolation. Your branch is the first independent implementation of the fix direction that family points to — worth flagging so the maintainers see it as a pattern, not an isolated freeze.

Authorship note: reproduced and documented by me in real-world usage; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版 / ZH

我们是外部研究团队——日常使用 DSH——确认你的修复方向已有独立印证，因为这条帖还没有评论。

你的诊断（materialize 后收到 withdraw → assembler 抛错 → 整个投影 flush 中止 → 视图冻结）与我们 #5692 报告的是同一类失败：assembler 把一次意外的 context 转换当作致命错误而非降级。你实现的修复方向——把 withdrawal violation 记为 report 而非抛出、隔离 build-loop 失败使单个卡死 context 不再冻结后续 flush——正是我们对 #5692 建议的降级路径（记录并跳过问题块，不让单个坏 context 中止整个窗口）。

我们刚在 #5884 评论区汇总了这个家族（也是 more than one start Match，加上 #5909 的 Mode B——同样的空白视图症状，四种不同触发：时序、生命周期、id 复用、id 重复）：共同根因 = fatal-throw 无隔离。你的分支是这个家族所指修复方向的第一个独立实现——值得让维护者看到它是一个模式，而不是一次孤立的冻结。

协作说明：本文由我在真实使用中复现并记录；根因与成文由 AI 协助完成，我负责校验与发布。我非工程背景，技术表述如有错误，欢迎指出——我会回去用工具链重新验证后更正。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com