[Bug] session/fork inherits the source's pending inbox — a branch's first new message is answered as the source's queued question ｜ fork 继承未消费收件箱：分支首条新消息被当成源分支排队提问回答

[MuShenYuan]

---

中文版

[Bug] session/fork 继承源会话未消费的收件箱，分支首条新消息被当成源会话的排队提问回答

版本： @deepseek-ai/dsh 0.1.5-rc.1 · Windows · Web GUI（端口 3080）

摘要

对会话点「创建分支」后，在分支里输入一个全新问题并发送 —— 分支实际跑的却是源会话在该节点的下一条排队提问，我真正的新问题被挤到队列尾部（或被降级为回合内注入）。而且这个问题会累积：每 fork 一代就多继承一条幽灵消息，多次分支后队列里全是幽灵。

根因：session/fork 选取种子前缀时，从最后一个 turn/end 向后推进到下一个 turn/start 才截断，于是把属于下一回合的 agent/inbox/spliced「插入」事件一起继承了；而待处理收件箱正是由这类事件折叠重建的持久投影。继承了「插入」却不继承它的「消费」，子会话重放后队列里就凭空多出源会话的提问，子会话首个新回合按 FIFO 从下标 0 取料，取到的就是幽灵。

不是客户端串会话：请求确实发到了子会话 id，是子会话的收件箱投影被污染。

修复建议：切点停止条件除 turn/start 外，再加上「向下一回合的收件箱插入」；并补一条「种子前缀收件箱不平衡」的错误日志便于回归。已在真实日志上离线复算：6 个分支开局残留 1+2+3+4+5+1=16 条 → 全部归 0，且不会丢弃任何已完成回合的历史（v3 事件的 surfaceOp 引用只向前指，截尾安全）。

当前可用规避：在已污染的分支里把「排队」面板的条目全部取消，投影清空后行为即恢复正常；或只在源会话空闲且队列为空时创建分支。

现象

对会话点「创建分支」（fork）后打开该分支，输入一个全新问题并发送。分支并不是从这个新问题开始的：

• 实际跑起来的是源分支在该节点上的提问（一条陈旧的排队提示词）；
• 我真正的新问题被静默地丢到队列尾部，或者以 steering 的形式被注入到回合中段。

而且它会累积：每多 fork 一代就多继承一条陈旧条目，fork 几次之后队列里就只剩幽灵了。

复现步骤

1. 在某个会话里完成一个回合，然后再发一条提示词（或者在一个较旧的节点上 fork，而此时已有更新的提示词被 splice 进下一回合的收件箱）。
2. 打开会话菜单 → 创建分支（可选从指定节点 fork，即带 atSeq）。
3. 在新分支里输入一条全新提示词（例如 hello）并回车。

期望：分支的首个新回合里只有 hello。
实际：分支的首个新回合里是源会话那条陈旧提问；hello 被排在它后面。

证据（真实会话日志，~/.dsh/sessions/<workspace>/）

fork 的切点正好落在一次收件箱插入与消费它的那个回合之间：

seq 774  turn/end                        <- fork 边界（最后一个已完成回合）
seq 775  agent/inbox/spliced  next-turn start=0 inserted=[<源会话的排队提问>]
seq 776  turn/start                      <- 未被继承
seq 779  user/message                    <- 消费动作，未被继承

子（fork 出来的）会话从被继承的插入事件重建出了非空收件箱；队列深度随 fork 代数递增：

分支	分支开局时的待处理收件箱	首条新消息发送后的实际行为
分支 A	1	新提示词 splice 到 start=1；该回合跑的是陈旧提问
分支 B	2	start=2；user/message = 源会话的陈旧提问
分支 C	3	同上
分支 D	4	同上
分支 E	5	输入 hello → splice 到 start=5；回合回答的是陈旧提问；手动取消 5 次（outcome=canceled）后才恢复正常
分支 F	1	幽灵 = 源会话最后一条已提交的提示词

（分支标签已匿名化为 A–F；这六个 fork 会话是同一个本地 workspace 里的一条真实链条，队列深度序列 1→2→3→4→5 正是逐代累积的体现。提示词文本已做脱敏。）

根因

session/fork 选取种子前缀时一路推进到下一个 turn/start，这就把下一回合的 agent/inbox/spliced 插入事件一并纳入了继承前缀：

// @deepseek-ai/dsh-api-session-controller — fork(request)
let cut = SessionLogOffset(boundary.seq + 1);
while (cut < source.events.length && source.events[cut]?.type !== "turn/start") cut = SessionLogOffset(cut + 1);
// ...
await this.ctx.agents.create({ sessionId: childId, seed: source.events.slice(0, cut), inheritedEventCount: cut /* ... */ });

而待处理收件箱恰恰是一个由这些事件折叠出来的持久投影（@deepseek-ai/dsh-agent-loop/inbox，key: "inbox"）：

const next = inbox.toSpliced(splice.start, removedCount, ...splice.inserted);

于是，一个在被继承前缀里找不到对应消费的插入事件，就把源会话的队列实体化到了子会话中；子会话的首个回合按 FIFO 从下标 0 取料 —— 取到的就是这个幽灵。

两点范围说明：

• 这不是客户端路由 bug：提示词确实到达了子会话 id，是子会话的收件箱投影被污染了。
• 两条 fork 路径都受影响 —— 从节点 fork（带 atSeq）和从最后已完成回合 fork（不带 atSeq，只要源会话有排队提示词即可触发）。

修复建议

切点应当停在任何属于下一回合的东西之前 —— 不只是 turn/start，还包括向下一回合收件箱的插入 —— 同时加一条种子不平衡断言以便诊断：

let cut = SessionLogOffset(boundary.seq + 1);
// 收件箱插入是下一回合的「输入」；继承它却不继承其消费，
// 会在 fork 出来的会话里复活源会话的待处理队列。
const belongsToNextTurn = (event: SessionEvent) =>
  event?.type === "turn/start" ||
  (event?.type === "agent/inbox/spliced" && (event.data?.inserted?.length ?? 0) > 0);
while (cut < source.events.length && !belongsToNextTurn(source.events[cut])) cut = SessionLogOffset(cut + 1);

const seed = source.events.slice(0, cut);
const unbalanced = seed.reduce(
  (acc, e) => (e.type === "agent/inbox/spliced" ? acc + e.data.inserted.length - (e.data.removedCount ?? 0) : acc),
  0,
);
if (unbalanced !== 0)
  ctx.logger.error(
    `session-controller: fork of "${request.sessionId}" inherits ${unbalanced} pending inbox message(s) at cut ${cut}`,
  );

用新的切点规则在上述六个真实分支上离线重放折叠过程验证：分支开局待处理数 16 → 0（分别为 1、2、3、4、5、1 → 全部为 0）。该规则只会丢弃被舍弃回合末尾的下一回合插入，因此不会丢失任何已完成回合的历史 —— v3 的 surfaceOp 引用只向后指，截尾是安全的。

替代/补充方案：在子会话的第一条自有事件里发一条补偿性的 agent/inbox/spliced（removedCount = pending，outcome: "canceled"），这样任何不平衡的种子都能自愈，且丢弃动作仍然可审计。

当前规避方式

• 在已经 fork 出的分支里，把队列面板中的条目全部取消 —— 收件箱投影一旦清空，新发送就恢复正常。
• 只在源会话空闲且队列为空时才创建分支。

环境

• @deepseek-ai/dsh 0.1.5-rc.1（npx 安装），Windows 11，Web GUI 服务在 127.0.0.1:3080
• 受影响功能：Web GUI 会话菜单 → 创建分支（session/fork）

---

English version

[Bug] session/fork inherits the source's pending inbox, so a branch's first new message is answered as the source's queued question

Version: @deepseek-ai/dsh 0.1.5-rc.1 · Windows · Web GUI (port 3080)

Summary

After forking a session, type a brand-new question in the branch and send it. The turn that actually runs is the source's queued prompt at that node, and the real question is pushed to the back of the queue (or downgraded to a mid-turn injection). It compounds: every additional fork generation inherits one more ghost message, so after a few forks the queue is nothing but ghosts.

Root cause: when session/fork picks the seed prefix, it advances from the last turn/end up to the next turn/start before cutting — so it also inherits the agent/inbox/spliced insert events that belong to the next turn. The pending inbox is a durable projection folded from exactly those events. Inheriting an insert without inheriting its consume makes the source's queued prompt reappear inside the child; the child's first new turn claims FIFO from index 0 and picks up the ghost.

This is not client-side session mixing: the request really does reach the child session id — it is the child's inbox projection that is poisoned.

Proposed fix: make the cut stop not only at turn/start, but also at any "insert into the next turn's inbox"; plus an unbalanced-seed error log for diagnosability. Verified offline against real logs: the six branches start with 1+2+3+4+5+1 = 16 residual entries → all 0, without dropping any completed-turn history (v3 event surfaceOp references point backwards only, so trimming the tail is safe).

Workaround today: in a polluted branch, cancel every entry in the queued panel — once the projection is empty, behaviour returns to normal; or only fork while the source session is idle with an empty queue.

Symptom

Create a branch (fork) of a session, open the branch, type a brand-new question and send it. The branch does not start with that question:

• the turn that actually runs is the source branch's question at that node (a stale queued prompt), and
• my real question silently drops to the back of the queue, or is injected mid-turn as steering.

It compounds: every extra fork generation inherits one more stale item, so after a few forks the queue is nothing but ghosts.

Reproduction

1. In a session, finish a turn, then send another prompt (or fork from an older node while a newer prompt has already been spliced into the next-turn inbox).
2. Open the session menu → Fork (optionally from a specific node, i.e. with atSeq).
3. In the new branch, type a fresh prompt (e.g. hello) and press Enter.

Expected: the branch's first new turn contains exactly hello.
Actual: the branch's first new turn contains the source's stale question; hello is queued behind it.

Evidence (real session logs, ~/.dsh/sessions/<workspace>/)

The fork cut sits between an inbox insert and the turn that consumes it:

seq 774  turn/end                        <- fork boundary (last completed turn)
seq 775  agent/inbox/spliced  next-turn start=0 inserted=[<source's queued question>]
seq 776  turn/start                      <- NOT inherited
seq 779  user/message                    <- the consume, NOT inherited

Child (forked) sessions reconstructed a non-empty inbox from the inherited insert; queue depth grows per fork generation:

branch	pending inbox at branch start	what the first new send did
branch A	1	new prompt spliced at start=1; the turn ran the stale question
branch B	2	start=2; user/message = source's stale question
branch C	3	same
branch D	4	same
branch E	5	typed hello → spliced at start=5; turn answered the stale question; only after 5 manual cancels (outcome=canceled) did it behave
branch F	1	ghost = the source's last committed prompt

(Branch labels are anonymized to A–F; the six forked sessions are a real chain in one local workspace, and the queue-depth sequence 1→2→3→4→5 is what shows the per-generation accumulation. Prompt texts are redacted.)

Root cause

session/fork picks the seed prefix by advancing to the next turn/start, which includes the next turn's agent/inbox/spliced inserts in the inherited prefix:

// @deepseek-ai/dsh-api-session-controller — fork(request)
let cut = SessionLogOffset(boundary.seq + 1);
while (cut < source.events.length && source.events[cut]?.type !== "turn/start") cut = SessionLogOffset(cut + 1);
// ...
await this.ctx.agents.create({ sessionId: childId, seed: source.events.slice(0, cut), inheritedEventCount: cut /* ... */ });

Meanwhile the pending inbox is a durable projection folded from exactly those events (@deepseek-ai/dsh-agent-loop/inbox, key: "inbox"):

const next = inbox.toSpliced(splice.start, removedCount, ...splice.inserted);

An insert with no matching consume inside the inherited prefix therefore materialises the source's queue inside the child, and the child's first turn claims FIFO from index 0 — i.e. the ghost.

Two notes on scope:

• This is not a client routing bug: the prompt does reach the child session id; the child's inbox projection is poisoned.
• Both fork paths are affected — fork-from-node (with atSeq) and fork-from-last-completed-turn (no atSeq, source merely has a queued prompt).

Proposed fix

Stop the cut before anything that belongs to the next turn — not only turn/start, but also next-turn inbox inserts — plus an unbalanced-seed assertion for diagnosability:

let cut = SessionLogOffset(boundary.seq + 1);
// An inbox insert is the *input* of the next turn; inheriting it without its consume
// resurrects the source's pending queue inside the forked session.
const belongsToNextTurn = (event: SessionEvent) =>
  event?.type === "turn/start" ||
  (event?.type === "agent/inbox/spliced" && (event.data?.inserted?.length ?? 0) > 0);
while (cut < source.events.length && !belongsToNextTurn(source.events[cut])) cut = SessionLogOffset(cut + 1);

const seed = source.events.slice(0, cut);
const unbalanced = seed.reduce(
  (acc, e) => (e.type === "agent/inbox/spliced" ? acc + e.data.inserted.length - (e.data.removedCount ?? 0) : acc),
  0,
);
if (unbalanced !== 0)
  ctx.logger.error(
    `session-controller: fork of "${request.sessionId}" inherits ${unbalanced} pending inbox message(s) at cut ${cut}`,
  );

Verified offline by replaying the fold with the new cut rule over the six real branches above: pending-at-branch-start 16 → 0 (1, 2, 3, 4, 5, 1 each → 0). The rule only ever drops trailing next-turn inserts of the discarded turn, so no completed-turn history is lost — v3 surfaceOp references point backwards only, so trimming the tail is safe.

Alternative / complementary: emit a compensating agent/inbox/spliced (removedCount = pending, outcome: "canceled") as the child's first own event, so any unbalanced seed self-heals and the discard stays auditable.

Workaround today

• In an already-forked branch, cancel every item in the queue panel — once the inbox projection is empty, new sends behave normally.
• Fork only from a source session that is idle and has an empty queue.

Environment

• @deepseek-ai/dsh 0.1.5-rc.1 (npx install), Windows 11, Web GUI served on 127.0.0.1:3080
• Affected feature: Web GUI session menu → Fork (session/fork), i.e. "创建分支".

[YukiZhang15]

这是来自zhangyueQQ邮箱的自动回复邮件。您好，您的邮件已收到，谢谢。

[Robin1987China]

你发现的「每 fork 一代就多继承一条幽灵消息」是这条缺陷最有说服力的一面 —— 它是可累积的，不是一次性异常。我在 master 上复现并做了个可挂载的修复。

已验证的修复：dsh-plugin-fork-inbox-guard

• npm：https://www.npmjs.com/package/dsh-plugin-fork-inbox-guard
• 源码 / 复现记录：https://github.com/Robin1987China/dsh-plugin-fork-inbox-guard （docs/verification.md）

我在 master aa8262ec091 上用真实的 sessionController.fork()（不是模拟）做了端到端复现，再挂上修复重跑：

运行	子会话 pendingNextTurn	子会话自有事件	父会话队列
未挂插件	含父会话排队消息 id	[]	未受影响
挂上插件	[]	一条持久 agent/inbox/spliced { removedCount: 1, outcome: "canceled" }	未受影响

关键代码路径（与各位的定位一致）

• packages/api/session-controller/src/commands.ts:243-246 — cut 从 boundary.seq + 1 一直推进到下一个 turn/start，把区间内的 agent/inbox/spliced 一起扫进子会话 seed
• packages/api/session-controller/src/commands.ts:263-268 — 该前缀作为 seed 与 inheritedEventCount，并打上 meta.isSeeded: true
• packages/core/agent-loop/src/inbox.ts:27-56 — inboxProjectionDefinition 折叠日志里全部 splice，完全不看 inheritedEventCount；而 packages/core/session/src/index.ts:607 其实已经在切点写了 session/end-seed { inherited: true } 标记，只是投影没读它

插件怎么修

在 agent/created 时，对 header.isSeeded 的会话，只重放 session.inheritedEventCount 之前的事件（按 inbox splice 规则折叠），得到「分叉那一刻正在排队」的精确 id 集合，再用 agent.inbox.remove(id) 持久地移除它们 —— 写入的是 agent/inbox/spliced，不是只改内存。子会话在切点之后为自己排队的新输入不受影响；非 seeded 会话一律不碰，所以 resume 回来的会话保留自己的队列。仓库里另有 12 个契约测试。

边界说明：这只是把解决方案打包成可挂载守护插件，不是上游补丁 —— bundle 补丁够不到 commands.ts 与 inbox 投影内部。真正的 upstream 修复仍应落在那处 cut 条件（或给 inboxProjectionDefinition 加 inheritedEventCount 判断）。在官方合入前，插件让现有部署立刻受益。

---

Verified fix: dsh-plugin-fork-inbox-guard

• npm: https://www.npmjs.com/package/dsh-plugin-fork-inbox-guard
• Source / raw reproduction transcripts: https://github.com/Robin1987China/dsh-plugin-fork-inbox-guard (docs/verification.md)

Reproduced end to end on master aa8262ec091 through the real sessionController.fork() (no mock), then re-run with the fix mounted:

Run	Child pendingNextTurn	Child own events	Parent queue
No guard	parent's queued id present	[]	intact
Guard mounted	[]	one durable agent/inbox/spliced { removedCount: 1, outcome: "canceled" }	intact

The relevant code paths are packages/api/session-controller/src/commands.ts:243-246 (the cut walks to the next turn/start, sweeping the agent/inbox/spliced into the seed), commands.ts:263-268, and packages/core/agent-loop/src/inbox.ts:27-56 (the projection folds every splice and never consults inheritedEventCount, even though packages/core/session/src/index.ts:607 already wrote a session/end-seed { inherited: true } marker at the cut).

The guard, on agent/created for a header.isSeeded session, replays only the events before session.inheritedEventCount, then durably removes exactly the identities that were pending at the cut. Input the child queued for itself after the cut is untouched, and non-seeded sessions are never touched.

Scope note: this is a mountable guard, not an upstream patch — a bundle patch cannot reach commands.ts or the inbox projection. The real fix still belongs in the cut condition above.

[Robin1987China]

补充：安装方式有更新。 这个修复现在也被 umbrella bundle dsh-community-fixes 收录 —— 它的目的就是免掉「每个修复各装一次、各挂一次」的麻烦：

dsh plugin --profile <你的 profile> add dsh-community-fixes

再把 dsh-community-fixes 加进该 profile 的 dsh.profile.bundles，一条线即可挂载全部已验证修复（每一个仍可在 profile 自己的补丁层里单独 disabled）。单独安装 dsh-plugin-fork-inbox-guard 依然有效。