Editing/revoking a session causes "turn-tail received an update before its start Match" on reopen — host history window pagination + turn-tail has zero tolerance for split turns

[yamingmou]

EN / English

Summary

Sessions containing replace markers fail to load on reopen with: conversation Context N:turn-tail received an update before its start Match (internal). The root cause is a client-side window pagination defect: history({ maxMessages: 50 }) loads a tail window, but when replace markers exist, shadowed nodes are excluded from visible-message counting — causing the window start to land mid-turn. The turn-tail matcher then receives turn/end before turn/start and throws.

This is a pure official DSH client defect (in dsh-client-runtime acceptMatch). Replace markers from any source (third-party edit/revert or official compaction) merely trigger it — the defect is the missing tolerance, not the marker.

Upstream status (checked against repo master, 2026-09-05): the received an update before its start Match throw is still present in packages/client/ui-conversation/src/client/conversation/assembler.ts (3 sites, no degradation path), and orphan step/start blocks written before turn/start still map to update role in the turn-tail matcher. Window pagination has since gained a sourceEventSeqs backtrace (paginate in session-controller/history.ts) which partially mitigates the replace-marker case — but the window cut lands at a message-group start, not a turn/start boundary, so a window can still open mid-turn and trip the same throw.

Trigger Condition

1. Session contains replace markers (third-party edit/revert or official compaction)
2. history({ maxMessages: 50 }) window start lands after a turn's turn/start
3. Client turn-tail matcher receives turn/end without prior turn/start → throw

Proposed Fix

1. turn-tail tolerance: update-before-start should degrade to "skip/ignore" instead of throwing — turnLocation/tailData already have null-tolerance paths
2. Window pagination with markers: window start should backtrack to nearest turn/start (ensuring complete turn structure within window)
3. Or: on update-before-start, shift window start back one turn boundary and retry

---

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.

中文版 / ZH

摘要

含 replace marker 的会话打开即报：历史加载失败：conversation Context N:turn-tail received an update before its start Match（internal）。根因是官方客户端窗口分页缺陷：history({ maxMessages: 50 }) 从尾部加载窗口，但 replace marker 存在时被遮蔽节点不计入可见消息 → 窗口起点落在某 turn 的 turn/start 之后 → turn-tail 匹配器先收到 turn/end 无 turn/start → 抛错。

这是纯官方 DSH 客户端缺陷（dsh-client-runtime acceptMatch）。任何来源的 replace marker（第三方编辑/撤回或官方 compaction）只是触发条件——缺陷在缺失的容错，不在 marker。

上游现状（对照仓库 master，2026-09-05）：received an update before its start Match 抛错在 packages/client/ui-conversation/src/client/conversation/assembler.ts 仍有三处、无降级路径；turn/start 之前写入的孤儿 step/start 块在 turn-tail 匹配器中仍映射为 update role。窗口分页（session-controller/history.ts 的 paginate）已新增 sourceEventSeqs 回溯——对 replace-marker 场景是部分缓解——但窗口起点落在消息源组起点而非 turn/start 边界，窗口仍可能从 turn 中间切开并触发同一抛错。

触发条件

1. 会话含 replace marker（第三方编辑/撤回或官方 compaction）
2. history({ maxMessages: 50 }) 窗口起点落在某 turn 的 turn/start 之后
3. 客户端 turn-tail 匹配器先收到 turn/end 无 turn/start → 抛错

建议修复

1. turn-tail 容错：update-before-start 应降级为"跳过/忽略"而非抛错
2. 含 marker 时的窗口分页：窗口起点应回溯到最近的 turn/start
3. 或：遇 update-before-start 时窗口起点前移一个 turn 边界重试

---

署名 / About

EN: Reported by the OfferKuai (Offer快) Team. Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com
ZH: 本报告由 OfferKuai（Offer快）团队提交。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com

Evidence chain and detailed analysis follow in the comments below.
（详细证据链与分析见下方跟帖。）

---

---

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

[yamingmou]

Follow-up — Evidence chain (session-side data + orphan-block scan)

1. Session data is healthy — this is not data corruption

Using the official foldSurface + loadSessionLog against affected sessions (4d6346da / 94fba202, both edited):

• turn/start ↔ turn/end pair 1:1 per turn (no duplicates, no missing);
• replace markers' sourceEventSeqs cover exactly the shadowed surface nodes;
• markers do not swallow turn/start (e.g. in 4d6346da the marker at seq 161 shadows 7-157, and turn/start t2 sits at 164 — outside the shadowed range): turn boundary events survive intact;
• official foldSurface replay passes with 0 errors.

So the log that the client refuses to open is the same log the data layer folds cleanly. The failure is in the client's loading path, not in the record.

2. Orphan step blocks are a general pattern — not exclusive to edited sessions

A full scan of 99 sessions found 11 sessions carrying "empty step blocks" — step/start + empty assistant/message + step/end (or step/start + step/end) floating before any turn/start:

• they appear in fresh, never-edited sessions too (e65e23b4 / 94fba202 / 4d6346da, independent root sessions);
• they come from the official agent loop's pre-step write pattern (an empty step block is written before each turn begins, ahead of turn/start);
• the client turn-tail matcher reports update-before-start on these orphans exactly the same as on window-cut turns → session fails to open.

This widens the trigger beyond "edited sessions": any session whose log contains a pre-step orphan block (a normal agent-loop write sequence) can hit the same throw on reopen.

3. Reproduction & session-side workaround

Reproduction: edit/revert any message in a session (a third-party edit op writes a replace marker), reopen the session → history loading failed: conversation Context N:turn-tail received an update before its start Match (internal).

Session-side workaround (does not fix the client): remove the orphan step blocks and renumber — after that dsh-log-contract check reports 0 violations, the official foldSurface passes, and the update-before-start count drops to zero on reopen. This confirms the throw is driven purely by client turn-tail matching over boundary-cut/orphan structures.

---

跟帖 — 证据链（会话侧数据 + 孤儿块扫描）

1. 会话数据 100% 健康——这不是数据损坏

用官方 foldSurface + loadSessionLog 验证受影响会话（4d6346da / 94fba202，均为编辑过的会话）：

• turn/start 与 turn/end 每 turn 恰好 1:1 配对（无重复无缺失）；
• replace marker 的 sourceEventSeqs 精确覆盖被遮蔽 surface 节点；
• marker 不吞 turn/start（如 4d6346da 的 marker 在 seq 161、遮蔽 7-157，turn/start t2 在 164——遮蔽范围外）：turn 边界事件完整保留；
• 官方 foldSurface 重放通过（0 错误）。

也就是说：客户端拒绝打开的日志，正是数据层能干净折叠的同一份日志。问题在客户端的加载路径，不在记录本身。

2. 孤儿 step 块是普遍模式——不只出现在编辑过的会话

全量扫描 99 个会话发现 11 个会话携带"空 step 块"——step/start + 空 assistant/message + step/end（或 step/start + step/end）悬在任何 turn/start 之前：

• 未编辑过的新会话也有（e65e23b4 / 94fba202 / 4d6346da，独立根会话）；
• 它们来自官方 agent 循环的 pre-step 写入模式（每个 turn 开始前先预写一个空 step 块，早于 turn/start）；
• 客户端 turn-tail 匹配器对这些孤儿块报 update-before-start，与窗口切开 turn 完全同路 → 会话打开失败。

这把触发范围从"编辑过的会话"扩大为：任何日志含 pre-step 孤儿块的会话（agent 循环的正常写入序列）都可能在同一抛错下重开失败。

3. 复现与会话侧缓解

复现：编辑/撤回会话中任意消息（第三方编辑操作写入 replace marker）→ 重开会话 → 历史加载失败：conversation Context N:turn-tail received an update before its start Match（internal）。

会话侧缓解（不修客户端）：移除孤儿 step 块并重编号后——dsh-log-contract check 0 违规、官方 foldSurface 通过、重开时 update-before-start 归零。这反向证明抛错纯粹由客户端 turn-tail 对被切开/孤儿结构的匹配驱动。

[yamingmou]

EN / English

Follow-up 2 — the fix this family needs: isolate, don't throw (2026-09-08)

One contract, three trigger classes, one fix. The four reports in this thread and its family (#5884, #5907, #5909) are not separate bugs — they all hit the same assembler.ts build/match contract, which fatal-throws (~17 such guards, none with per-context isolation) on any unexpected context transition and freezes the whole conversation instead of skipping one bad block.

Since this thread was posted (2026-09-05), three more reports have landed on the same core claim — the assembler aborts the whole window on a single unexpected context transition. Recommended fix first, evidence below.

The fix (one code change, covers all four): in ConversationNodeAssembler, when one context violates the matcher's expectations — log it, skip that block, and keep building — instead of throwing and blanking the window. Per-context failure isolation with a report. @northwang-lucky's fix branch for #5907 already implements exactly this (withdrawal violation → report + isolated build-loop entries, tests green); it is the first independent implementation of the direction we proposed in Follow-up 1.

Two refinements, in order:

1. Isolate per-context build failures + report (the defensive layer — makes replayed history robust to all malformed-but-present data, including sessions already written; Bug: Chat view freezes after loading earlier history — root cause found, fix branch ready #5907's branch is the proof it works)
2. @argszero's key-scoping ((kind, id, stepSeq)) as a targeted refinement for the id-reuse class only — it cannot cover the other three triggers (below), so it should not be the whole fix
3. Producer-side id uniqueness as the going-forward fix

Why — four triggers, one shared behavior:

Trigger	Report	Error
Sequencing (window lands mid-turn after replace markers)	this thread (#5692)	turn-tail received an update before its start Match
Lifecycle (withdraw after materialization)	#5907 (@northwang-lucky)	withdrew materialized target
Id reuse across steps	#5884 (@Yikanji)	received more than one start Match
Id duplication within a step	#5909 Mode B (@jhugard)	received more than one start Match

Not four isolated points — a full master sweep (2026-09-08, packages/client/ui-conversation/src/client/conversation/assembler.ts, 958 lines) shows ~17 Match-guard throws of this kind (update before its start ×3, more than one start ×2, withdrew materialized target, plus duplicate/transient/non-appended/inconsistent-identity/unstable-key guards), none with a per-context isolation path. Isolation + report is therefore the systematic fix for the file, not a patch for one error string.

@argszero source-verified #5884 (assembler.ts:513 acceptMatch / :569 applyPendingMatches) and proposed key-scoping — correct for id reuse, but it cannot help update-before-start (no key collision to disambiguate) or withdraw-after-materialization (the collision is with the assembler's own state machine, not the key). Key-scoping alone leaves the sequencing and lifecycle classes broken, and the next unforeseen trigger produces a fifth report. Isolation + report covers all four — that is the one change that turns these discussions into a single code fix.

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

跟帖2 — 这个家族需要的修复：隔离，而不是抛出（2026-09-08）

一个契约、三类触发、一个解法。 本帖与其家族报告（#5884、#5907、#5909）不是四个独立 bug——它们都命中同一个 assembler.ts build/match 契约，该契约对任何意外 context 转换都 fatal-throw（约 17 处此类守卫，均无逐 context 隔离），冻结整个会话而不是跳过那一个坏块。

自本帖发布（2026-09-05）以来，又有三份报告落在同一核心主张上——assembler 因单个意外 context 转换中止整个窗口。先给修复建议，证据在后。

修复方案（一处代码改动，覆盖全部四种）： 在 ConversationNodeAssembler 中，当某个 context 违反匹配器预期时——记录、跳过该块、继续构建——而不是抛出并清空窗口。逐 context 失败隔离 + report。@northwang-lucky 针对 #5907 的 fix branch 已经精确实现了这一点（withdrawal violation → report + 隔离 build-loop 入口，测试绿）；它是我们在跟帖1 所提方向的第一个独立实现。

两个细化，按序：

1. 逐 context 隔离构建失败 + report（防御层——让重放历史对所有"畸形但存在"的数据健壮，包括已落盘会话；Bug: Chat view freezes after loading earlier history — root cause found, fix branch ready #5907 的分支就是它可行的证明）
2. @argszero 的 key 消歧（(kind, id, stepSeq)）仅作为 id 复用类的定向细化——它覆盖不了下面其他三种触发，所以不应是全部修复
3. 写端 id 唯一作为治本

为什么——四种触发，一个共同行为：

触发	报告	报错
时序（replace marker 后窗口落在 turn 中间）	本帖（#5692）	turn-tail received an update before its start Match
生命周期（materialize 后收到 withdraw）	#5907（@northwang-lucky）	withdrew materialized target
跨 step 的 id 复用	#5884（@Yikanji）	received more than one start Match
step 内 id 重复	#5909 Mode B（@jhugard）	received more than one start Match

不是四个孤立点——2026-09-08 对 master 全量核验（packages/client/ui-conversation/src/client/conversation/assembler.ts，958 行）显示约 17 处此类 Match-guard throw（update before its start ×3、more than one start ×2、withdrew materialized target，另有 duplicate/transient/non-appended/inconsistent-identity/unstable-key 守卫），均无逐 context 隔离路径。隔离 + report 因此是对整个文件的系统性修复，而非对某条错误串的补丁。

@argszero 已源码核实 #5884（assembler.ts:513 acceptMatch / :569 applyPendingMatches）并提出 key 消歧——对 id 复用类正确，但救不了 update-before-start（没有 key 冲突可消歧），也救不了 withdraw-after-materialization（冲突在装配器自己的状态机，不在 key）。只做 key 消歧，时序与生命周期两类仍损坏，下一个未预见触发会带来第五份报告。隔离 + report 覆盖全部四种——这才是把这些讨论变成一处代码修复的那一步。

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

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