[Bug] [Update] Orphan agent/inbox/spliced splits log validity from session readability — impact upgrade: a routine post-incident repair can produce a durably intact but unreadable session (self-review of our own bug report)

[yamingmou]

Self-review update — correction of our own submitted bug report / 自我修正：对本人提交的 bug report 的修正 (2026-08-22)

⚠️ This is a self-review of the bug report we submitted. The original report described the failure as "the conversation UI hard-fails (blank paging)" — a UI-level symptom. After re-reading the engine source, we are upgrading the report to the layer where the defect actually lives: one log, two consumers, two verdicts. The same session log containing an orphan agent/inbox/spliced is declared valid by the persistence layer and unreadable by the session history consumption path. That split — not the blank page — is the defect.

TL;DR — EN: We originally reported "the conversation UI hard-fails (blank paging) on orphan agent/inbox/spliced ops with no insert." Upgrade: a log containing an orphan removal (removedCount > 0, no preceding inserted) is accepted by the persistence layer (foldSurface() passes; seq contiguous; JSON valid), yet the same log consumed by the session history path renders only up to the orphan op and returns empty pages for everything after — with no error surfaced. The inbox state machine's own reducer intends this tolerance (applySplice, dsh-client-ui-conversation/lib/client.js:8103-8113, safe defaults like removedCount ?? 0), but the consumption-side fold has no matching guard (dsh-client-runtime/lib/client.js:6345-6592 guards structure only) — the intended semantics do not hold end-to-end. The logs most likely to contain this state are exactly the ones produced by torn writes, crashes, or manual repair, so a routine post-incident recovery can silently produce a session that is durably intact yet unreadable.

一句话（中文）： 这是对本人提交的 bug report 的自我修正（升级）。原报告把故障描述为"对话 UI 硬失败（空白分页）"——那只是症状。重审源码后升级到缺陷真正所在的层：同一份日志，两个消费方，两种结论。含孤儿 agent/inbox/spliced（removedCount > 0、前面没有 inserted）的日志，被持久化层判定为合法（foldSurface() 通过、seq 连续、JSON 合法），却被会话历史消费路径判定为不可读——只渲染到孤儿操作之前、其后全部空页、无任何报错。inbox 状态机自己的 reducer 本意容忍此情形（applySplice，dsh-client-ui-conversation/lib/client.js:8103-8113，安全默认如 removedCount ?? 0），但消费侧 fold 没有同款守卫（dsh-client-runtime/lib/client.js:6345-6592 只守卫结构）——意图语义未能端到端兑现。最可能包含此状态的日志，恰恰是 torn write、崩溃或手工修复产生的那些，因此一次例行的事故后恢复可能静默产出"数据完好但不可读"的会话。

What we originally claimed / 初版表述 (EN): the conversation UI hard-fails (blank paging) on orphan agent/inbox/spliced ops with no insert; no data loss on disk, total loss of UI access.
What we now state / 现修正 (EN): upgraded to the log/state-machine layer — one log is declared valid by the persistence layer and unreadable by the session history consumption path; the inbox state machine's tolerance intent (visible in applySplice) does not hold end-to-end; the split sits exactly on the post-incident recovery path, so a routine repair can silently produce a durably intact but unreadable session.

初版表述（中文）： 孤儿 agent/inbox/spliced 撤回操作（无对应插入）导致对话 UI 渲染中断、分页空白；磁盘数据未丢，但 UI 完全无法访问。
现修正（中文）： 升级到日志/状态机层——同一份日志被持久化层判定合法、却被会话历史消费路径判定不可读；inbox 状态机的容错意图（applySplice 可见）未能端到端兑现；分裂恰好落在事故后恢复路径上，因此一次例行修复可能静默产出"数据完好但不可读"的会话。

---

EN / English

Version note / 版本说明

Source references were verified on @deepseek-ai/dsh 0.1.0-rc.7 and re-verified on 0.1.1-rc.2 — module internals unchanged, line numbers shifted:

• dsh-client-ui-conversation/lib/client.js: applySplice now at :8558-8568 (was :8103-8113).
• dsh-client-runtime/lib/client.js: the conversation fold/assembler now at :6358-6590 (was :6345-6592); structural guards at :6543 / :6567 / :6568 (was :6548 / :6572 / :6573); the history-error swallow now at :7414 (was :7418-7419).

Observed behavior

A session log containing an agent/inbox/spliced event with removedCount > 0 but no preceding inserted (an orphan removal) is accepted by the persistence layer — foldSurface() passes, seq stays contiguous, JSON is valid. The same log, consumed by the session history path, renders only up to the orphan op and returns empty pages for everything after — with no error surfaced (consumption errors are swallowed with a console-only log, dsh-client-runtime/lib/client.js:7418-7419).

One log, two consumers, two verdicts: "valid" (persistence) and "unreadable" (history consumption). The blank-page symptom is real; the defect is the split itself.

State-machine mechanism (with source references)

• The tolerance was intended. The inbox reducer applySplice (dsh-client-ui-conversation/lib/client.js:8103-8113) is written to be safe by default — removedCount ?? 0, pending.splice(...) against a possibly-empty array. An orphan removal is anticipated and tolerated at the reducer level.
• The same state machine has no matching guard downstream. The consumption-side fold/assembler (dsh-client-runtime/lib/client.js:6345-6592) guards structural violations only — duplicate starts (:6548), out-of-order appends (:6572), updates before a start (:6573) — with no guard for "removed identities that were never inserted."
• The intended semantics of the inbox state machine therefore do not hold end-to-end: the reducer tolerates, the consumption path does not.

Impact scope (upgraded — log / session / business / recovery path)

• Log layer: the trigger state is the residue of real incidents — a torn write on shutdown, a crash mid-append, or a manual repair after an outage. It is not an exotic input; it is what production incidents produce.
• Session layer: durable records are intact and yet the session is not reproducible — "the data is there, but the session cannot be restored." The split between log validity and session readability is the core hazard.
• Business layer: post-incident recovery is a routine operation and is trusted; this defect makes the repair path itself silently produce a zombie session, hiding the progress that survived the incident. Recovery tooling cannot report whether a repair actually succeeded.
• The only fixes today are data-layer operations (e.g. setting removedCount to 0 by manual log editing).

Expected behavior

The inbox state machine must have one semantics across all consumers: "removedCount against identities never inserted" must be a no-op everywhere (or surface a visible warning) — the reducer already does this, the consumption path must too. Data-layer strictness and consumption-layer tolerance must be aligned, and any alignment failure must surface as an error, never a silent blank.

Repro

1. Have a session log with an agent/inbox/spliced containing removedCount: 1 and no matching insert (can be produced by truncating the log between an insert and its removal).
2. Open the session; read earlier history → empty pages, no error.
3. Verification of causality: set removedCount to 0 → rendering and paging fully restored.

Environment

• Engine: @deepseek-ai/dsh 0.1.0-rc.6 / 0.1.0-rc.7
• Also verified on: @deepseek-ai/dsh 0.1.1-rc.2
• Session format: multi-frame zstd JSONL, strict contiguous seq

Evidence (sanitized + source)

seq 199843: {"type":"agent/inbox/spliced","data":{"target":"next-turn","start":0,"removedCount":1,"inserted":[]}}
   ^ orphan: removedCount=1 but inbox is empty (no prior inserted)

• dsh-client-ui-conversation/lib/client.js:8103-8113 — applySplice: intended tolerance (removedCount ?? 0, safe splice on empty pending).
• dsh-client-runtime/lib/client.js:6345-6592 — consumption fold/assembler: structural guards only; no orphan-removal guard.
• dsh-client-runtime/lib/client.js:7418-7419 — consumption errors are swallowed silently (console only).

---

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

版本说明

源码引用在 @deepseek-ai/dsh 0.1.0-rc.7 上验证，并在 0.1.1-rc.2 上重新验证——模块内部逻辑未变，行号有偏移：

• dsh-client-ui-conversation/lib/client.js：applySplice 现位于 :8558-8568（原 :8103-8113）。
• dsh-client-runtime/lib/client.js：对话 fold/assembler 现位于 :6358-6590（原 :6345-6592）；结构性守卫位于 :6543 / :6567 / :6568（原 :6548 / :6572 / :6573）；历史错误吞掉现位于 :7414（原 :7418-7419）。

现象

含有 agent/inbox/spliced 事件（removedCount > 0、前面没有对应的 inserted，即孤儿撤回）的会话日志，被持久化层接受——foldSurface() 通过、seq 连续、JSON 合法。同一份日志，被会话历史消费路径处理时，只渲染到孤儿操作之前，其后全部空页——且无任何报错（消费错误被吞掉、仅 console，dsh-client-runtime/lib/client.js:7418-7419）。

同一份日志、两个消费方、两种结论："合法"（持久化）与"不可读"（历史消费）。空白页症状真实存在；缺陷是分裂本身。

状态机机制（附源码引用）

• 容错本是有意的。 inbox reducer applySplice（dsh-client-ui-conversation/lib/client.js:8103-8113）按默认安全编写——removedCount ?? 0、对可能为空的数组做 pending.splice(...)。孤儿撤回在 reducer 层是被预见并容忍的。
• 同一个状态机在下游没有同款守卫。 消费侧 fold/assembler（dsh-client-runtime/lib/client.js:6345-6592）只守卫结构性违规——重复 start（:6548）、乱序追加（:6572）、start 之前 update（:6573）——对"撤回从未插入过的身份"没有任何守卫。
• 因此 inbox 状态机的意图语义未能端到端兑现：reducer 容忍，消费路径不容忍。

影响范围（升级 —— 日志 / 会话 / 业务 / 恢复路径）

• 日志层： 触发状态是真实事故的残留物——关机 torn write、追加中途崩溃、故障后手工修复。它不是奇异输入，而是生产事故真实产生的东西。
• 会话层： 持久化记录完好、但会话不可复现——"数据在，但会话无法恢复"。日志合法性与会话可读性之间的分裂是核心危害。
• 业务层： 事故后恢复是例行操作、且被信任；此缺陷让修复路径本身静默产出僵尸会话，遮蔽事故中幸存的进度。恢复工具无法报告"修复是否真的成功"。
• 当前唯一出路是数据层操作（如手工把 removedCount 改为 0）。

期望行为

inbox 状态机必须在所有消费方上语义一致："对从未插入过的身份执行 removedCount"在所有地方都应是空操作（或给出可见警告）——reducer 已经做到，消费路径也必须做到。数据层的严格与消费层的容错应当对齐，任何对齐失败必须以错误形式暴露，绝不允许静默空白。

复现步骤

1. 构造一个包含 agent/inbox/spliced（removedCount: 1、无匹配插入）的会话日志（在"插入"与"撤回"之间截断即可产生）。
2. 打开会话，读取更早历史 → 空页，无报错。
3. 因果验证：把 removedCount 改为 0 → 渲染与分页完全恢复。

环境

• 引擎：@deepseek-ai/dsh 0.1.0-rc.6 / 0.1.0-rc.7
• 另已在：@deepseek-ai/dsh 0.1.1-rc.2 上验证
• 会话格式：多帧 zstd JSONL，seq 严格连续

证据（脱敏 + 源码）

seq 199843: {"type":"agent/inbox/spliced","data":{"target":"next-turn","start":0,"removedCount":1,"inserted":[]}}
   ^ 孤儿：removedCount=1 但 inbox 为空（前面没有 inserted）

• dsh-client-ui-conversation/lib/client.js:8103-8113 —— applySplice：意图宽容（removedCount ?? 0、对空 pending 安全 splice）。
• dsh-client-runtime/lib/client.js:6345-6592 —— 消费侧 fold/assembler：只有结构性守卫，没有孤儿撤回守卫。
• dsh-client-runtime/lib/client.js:7418-7419 —— 消费错误被静默吞掉（仅 console）。

---

Original report (archived for transparency) / 初版报告（归档保留）

以下为初版表述（被上方"自我修正"升级）。保留以透明展示我们修正了什么。

EN

Observed behavior (original). After a session log is damaged/truncated (crash, manual repair, torn write), it can contain an agent/inbox/spliced event with removedCount > 0 but no preceding inserted. The persistence layer accepts the log, but the UI renders only up to the orphan op and "Load earlier" returns blank pages forever — with no error surfaced.

Impact scope (original). Any user who repairs/recovers a session (or suffers a torn write) can end up with a session that looks openable but is effectively unreadable in the UI. No data loss on disk; total loss of UI access to the conversation. Applies to web UI and desktop shell alike.

中文

现象（初版）。 会话日志受损/被截断后，可能残留一个 agent/inbox/spliced 事件：removedCount > 0 但前面没有对应的 inserted。持久化层接受这份日志，但 UI 只渲染到孤儿操作之前，"加载更早"永久空白，且没有任何报错。

影响范围（初版）。 任何修复/恢复过会话（或遭遇写入中断）的用户，都可能得到一个"看着能打开、实际读不了"的会话。磁盘数据未丢，但 UI 完全无法访问该对话。Web UI 与桌面壳同样受影响。

---

署名 / About this report

EN: Reported by the OfferKuai (Offer快) Team — an AI startup building full-lifecycle job-application services, guided by the belief that "users need results, not repeated conversations." Founder: Zhaofeng (Yaming). We use DeepSeek Harness as part of our daily development workflow; this report is our way of contributing back to the ecosystem. Website: https://www.offerkuai.com/ | Contact: <contact@offerkuai.com>

ZH: 本报告由 OfferKuai（Offer快）团队提交 —— 一家专注 AI 全流程求职托管的创业团队，核心理念是「用户要的是结果，不是重复对话」。创始人：Zhaofeng（Yaming）。我们将 DeepSeek Harness 用于日常开发工作流，这份报告是我们对社区的回馈。官网：https://www.offerkuai.com/ | 联系：<contact@offerkuai.com>

————————————————————————————————————————————————

## EN / English

### Observed behavior

After a session log is damaged/truncated (crash, manual repair, torn write), it can contain an `agent/inbox/spliced` event with `removedCount > 0` but **no preceding `inserted`** (an orphan removal). In that state:

- the persistence layer accepts the log (`foldSurface()` passes, seq is contiguous, JSON valid),
- but the **UI** renders only up to the orphan op and "Load earlier" returns blank pages forever — with no error surfaced.

### Expected behavior

The inbox state machine should treat a `removedCount` against an empty inbox as a **no-op** (or surface a visible warning), never brick the whole conversation rendering. Data-layer strictness and UI-layer tolerance should be aligned.

### Impact scope

- Any user who repairs/recovers a session (or suffers a torn write) can end up with a session that **looks openable but is effectively unreadable in the UI**.
- No data loss on disk; total loss of UI access to the conversation.
- Applies to web UI and desktop shell alike.

### Repro

1. Have a session log with an `agent/inbox/spliced` containing `removedCount: 1` and no matching insert (can be produced by truncating the log between an insert and its removal).
2. Open the session; click "Load earlier" → blank pages, no error.

### Environment

- Engine: `@deepseek-ai/dsh` `0.1.0-rc.6` / `0.1.0-rc.7`
- Session format: multi-frame zstd JSONL, strict contiguous seq

### Evidence (sanitized)

```
seq 199843: {"type":"agent/inbox/spliced","data":{"target":"next-turn","start":0,"removedCount":1,"inserted":[]}}
   ^ orphan: removedCount=1 but inbox is empty (no prior inserted)
```

Setting `removedCount` to `0` (no-op) restores full rendering and paging.

---

## 中文版 / ZH

### 现象

会话日志受损/被截断后（崩溃、手工修复、写入中断），可能残留一个 `agent/inbox/spliced` 事件：`removedCount > 0` 但**前面没有对应的 `inserted`**（孤儿撤回）。此时：

- 持久化层接受这份日志（`foldSurface()` 通过、seq 连续、JSON 合法）；
- 但 **UI 只渲染到孤儿操作之前**，"加载更早"永久空白，且**没有任何报错**。

### 期望行为

inbox 状态机应把"对空 inbox 执行 removedCount"视为**空操作**（或给出可见警告），绝不能让整个对话渲染瘫痪。数据层的严格与 UI 层的容错应当对齐。

### 影响范围

- 任何修复/恢复过会话（或遭遇写入中断）的用户，都可能得到一个"**看着能打开、实际读不了**"的会话。
- 磁盘数据未丢，但 UI 完全无法访问该对话。
- Web UI 与桌面壳同样受影响。

### 复现步骤

1. 构造一个包含 `agent/inbox/spliced`（`removedCount: 1`、无匹配插入）的会话日志（在"插入"与"撤回"之间截断即可产生）。
2. 打开会话，点"加载更早" → 空白页，无报错。

### 环境

- 引擎：`@deepseek-ai/dsh` `0.1.0-rc.6` / `0.1.0-rc.7`
- 会话格式：多帧 zstd JSONL，seq 严格连续

### 证据（脱敏）

```
seq 199843: {"type":"agent/inbox/spliced","data":{"target":"next-turn","start":0,"removedCount":1,"inserted":[]}}
   ^ 孤儿：removedCount=1 但 inbox 为空（前面没有 inserted）
```

把 `removedCount` 改为 `0`（空操作）后，渲染与分页完全恢复。

---

## 署名 / About this report

**EN:** Reported by the **OfferKuai (Offer快) Team** — an AI startup building full-lifecycle job-application services, guided by the belief that *"users need results, not repeated conversations."* Founder: **Zhaofeng (Yaming)**. We use DeepSeek Harness as part of our daily development workflow; this report is our way of contributing back to the ecosystem. Website: <https://www.offerkuai.com/> | Contact: <[contact@offerkuai.com](mailto:contact@offerkuai.com)>

**ZH:** 本报告由 **OfferKuai（Offer快）团队**提交 —— 一家专注 AI 全流程求职托管的创业团队，核心理念是「用户要的是结果，不是重复对话」。创始人：**Zhaofeng（Yaming）**。我们将 DeepSeek Harness 用于日常开发工作流，这份报告是我们对社区的回馈。官网：<https://www.offerkuai.com/> | 联系：<[contact@offerkuai.com](mailto:contact@offerkuai.com)>

---

*

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

[jlfei35]

Independent reproduction + self-hosted repair tool

Affected: @deepseek-ai/dsh@0.1.2-rc.1 (verified 2026-09-07 on Windows, npm latest still 0.1.2-rc.1).

We hit the same orphan-spliced issue on 4 sessions in our install, all still on 0.1.2-rc.1. Each affected session ends with an agent/inbox/spliced event of shape {target:next-turn, removedCount:1, inserted:[]} followed by a seq jump in the next chunk-row's seq0 (delta −2 to −219 depending on how many expanded events the spliced was supposed to consume). Stale surfaceOpRange values (one per orphan spliced) survive and reference event indexes that no longer exist.

Evidence (4 sessions, all on 0.1.2-rc.1)

session	records	expanded events	spliced count	surface-op fixes needed	first gap
19839527-… (current 2.3MB)	27134	325143	178	401	none
19839527-… (pre-repair 7.7MB)	27134	325143	178	114	idx=24659, delta=−2
6140c108-…	8319	203779	24	234	none
5184e10c-…	97197	1637530	1470	3662	none
1cd124f1-…	166294	3157644	1812	5807	none

Pre-repair .zstd backups preserved next to each session for inspection. The "current 2.3MB" vs "pre-repair 7.7MB" for session 19839527 contain the same logical records (27134) — only the on-disk frame count differs (5 vs 21639). The pre-repair version is the one that actually fails the consumeEventLine seq check; the current one passes it (with stale surface-op ranges that the runtime tolerates but never resolves).

Self-hosted repair

While waiting for the upstream fix, I built a self-contained repair tool that lives outside the dsh package (no plugin install, no schema change). It does the same accounting the runtime does (uses dsh's own decodeStorageRecord to expand text-chunks / reasoning-chunks / tool-call-chunks records by member count, not by record count), renumbers seq / seq0 contiguously from 0, clamps surfaceOpRange and sourceEventSeqs to the new event count, and re-zstd's a single frame at level 3. Original is backed up to *.pre-surgeon-<ts>.zstd next to it.

Verified end-to-end on all 4 sessions: dry-run → apply → re-run reports alreadyHealthy: true. File sizes shrink 0.5–2.5% (better zstd packing). No records dropped, no chunk-row content lost, spliced events kept as-is (only their surfaceOpRange is clamped).

If anyone wants a copy of the tool while the upstream fix is in flight, happy to share.

Suggested upstream fix (additive to the report above)

1. Drop orphan spliced records on persist. When agent/inbox/spliced is written without a matching agent/inbox event in the log, refuse to persist it (or persist it but exclude it from consumeEventLine's count). This is the root cause of the seq jump.

2. Honour removedCount when computing next record's seq/seq0. Right now the next chunk-row's seq0 is set to the post-removal event count, but consumeEventLine advances by the post-expansion event count. The two counters have to agree.

3. Clamp surfaceOpRange and sourceEventSeqs on persist to within the current event count. They currently get written pointing at future indexes that may never exist if a downstream splice actually fires.

4. Surface the corruption earlier. dsh's "session.list" passes on these files; the seq-gap error only fires when you actually open the session. A startup-time scan (e.g. on profile boot) would catch this before the user wastes time on a session that won't load.