[Bug] Cancelling a task that spawned subagents permanently corrupts session persistence — production data integrity failure, no recovery path for operators

[yamingmou]

EN / English

Observed behavior

In a production-like workflow: a task spawns subagents (via the subagent tool), then the user cancels / aborts the task (stop button, interrupt, or re-send). After this:

1. The parent session gains turn/end events with reason.kind: "aborted" at its tail. Repeated cancellations accumulate multiple aborted turns.
2. The subagent sessions (forked child sessions) are left hanging: their logs contain unclosed turn/start / step/start and tool/call entries with no matching tool/result.
3. Eventually the parent session fails to load entirely — the persistence layer refuses the log ("history unavailable"), the session becomes unreadable, and the data, though present on disk, is effectively lost to the user.

This is not a one-off: it reproduces every time a task with subagents is cancelled or re-sent.

Expected behavior

• Cancelling a task is a normal, first-class operation in production (manual abort, timeout, re-queue). It must not leave permanent corrupting artifacts in session persistence.
• Aborted turns should be recoverable / resumable markers, not terminal states that make the session unusable.
• Child (subagent) sessions should be closed cleanly (or explicitly marked abandoned) when the parent task is cancelled — not left with unclosed turns/steps forever, leaking persistence state.
• The system must degrade gracefully: preserve data integrity and accessibility after a cancellation, without requiring manual log surgery.

Impact scope (production focus)

• High-frequency operation: cancelling/re-sending agent tasks (especially ones that spawn subagents) is routine in production. Every occurrence deposits corrupting artifacts + hanging subagent sessions.
• Sessions degrade cumulatively — each cancellation moves the session closer to permanent unreadability.
• Data integrity failure: the persisted log becomes logically inconsistent (seq/state violations) while the file itself looks intact on disk — the worst kind of failure to diagnose.
• No recovery path for operators: restoring the session today requires manual, surgical, byte-level log editing (frame-accurate truncation + seq repair). This is not achievable by a production operator or non-technical user.
• The corruption lives in the shared persistence layer, so every consumer of the session data is affected — no entry point can read the session once the log is rejected.

Repro

1. In a session, issue a command that spawns subagents (e.g. the subagent tool).
2. While it runs, cancel (or re-send the message).
3. Repeat 2–3 times.
4. Reopen the parent session → the persistence layer rejects the log; the session is unreadable.

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 (session.jsonl.zstd), strict contiguous seq from 0
• Subagent tool: subagent (spawns child sessions under ~/.dsh/sessions/...)

Evidence (sanitized)

Parent session tail after cancelling twice:

turn 47: turn/end reason=completed      <- last good turn
turn 48: turn/end reason=aborted       <- from cancellation #1
turn 49: turn/end reason=aborted       <- from cancellation #2
session/end-seed

Hanging subagent sessions (children of the parent):

subagent A: unclosed turn/start, unclosed step/start
subagent B: unclosed turn/start, unclosed step/start, tool/call with no matching tool/result

Recovery only worked after truncating the parent log at turn 47's turn/end (frame-accurate surgery); the subagent sessions remain in a permanently inconsistent state.

---

中文版 / ZH

现象

在生产类工作流中：任务通过 subagent 工具启动子 agent，然后用户取消/中止该任务（停止按钮、中断、或撤回重发）。此后：

1. 父会话尾部产生 reason.kind: "aborted" 的 turn/end。反复取消会累积多个 aborted 轮次。
2. 子 agent 会话（fork 出的子会话）被悬挂：日志里残留未闭合的 turn/start / step/start，以及没有对应 tool/result 的 tool/call。
3. 最终父会话整体加载失败——持久化层拒绝该日志（"历史不可用"），会话不可读；数据虽在磁盘上，但事实上已对用户丢失。

这不是偶发：每次取消/重发带子 agent 的任务都会复现。

期望行为

• 取消任务是生产环境的正常一等操作（人工中止、超时、重新排队）。它绝不能在会话持久化中留下永久损坏痕迹。
• aborted 轮次应是可恢复/可继续的标记，而不是让会话不可用的终态。
• 父任务被取消时，子（subagent）会话应被干净关闭（或明确标记为废弃），而不是永远挂着未闭合的 turn/step、泄漏持久化状态。
• 系统必须优雅降级：取消后保持数据完整性与可访问性，无需人工日志手术。

影响范围（生产视角）

• 高频操作：取消/重发 agent 任务（尤其带子 agent 的）在生产中是常规动作。每一次都在持久化中沉积损坏痕迹 + 悬挂的子会话。
• 会话累积性劣化——每次取消都让会话离"永久不可读"更近一步。
• 数据完整性失败：持久化日志变得逻辑不一致（seq/状态违规），但磁盘文件看起来完好——这是最难以诊断的失败类型。
• 运维人员无恢复路径：当前恢复需要手工、外科手术式、字节级日志编辑（帧级截断 + seq 修复）——生产运维或非技术用户无法完成。
• 损坏位于共享持久化层，因此所有会话数据消费者均受影响——日志一旦被拒绝，任何入口都无法读取该会话。

复现步骤

1. 在会话中下达一条会启动子 agent 的命令（例如 subagent 工具）。
2. 运行中取消（或撤回重发）。
3. 重复 2–3 次。
4. 重新打开父会话 → 持久化层拒绝该日志；会话不可读。

环境

• 引擎：@deepseek-ai/dsh 0.1.0-rc.6 / 0.1.0-rc.7
• 另已在：@deepseek-ai/dsh 0.1.1-rc.2 上验证
• 会话格式：多帧 zstd JSONL（session.jsonl.zstd），seq 从 0 严格连续
• 子 agent 工具：subagent（在 ~/.dsh/sessions/... 下派生子会话）

证据（脱敏）

父会话尾部（取消两次后）：

turn 47: turn/end reason=completed      <- 最后一个正常轮次
turn 48: turn/end reason=aborted       <- 第一次取消产生
turn 49: turn/end reason=aborted       <- 第二次取消产生
session/end-seed

悬挂的子 agent 会话（父会话的子会话）：

subagent A: 未闭合 turn/start、未闭合 step/start
subagent B: 未闭合 turn/start、未闭合 step/start、无对应 tool/result 的 tool/call

只有把父日志截断到 turn 47 的 turn/end（帧级手术）后会话才恢复可读；子会话仍处于永久不一致状态。

---

署名 / 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>

[yamingmou]

#3664