[Bug][0.1.5-rc.x] Fork 出的会话发送新消息时重放源会话旧 prompt（A），新 prompt（B/C）永久滞留队列不执行

[x2410516039]

版本基线：DSH 【 0.1.5-rc.2】。本文为行为级复现报告，未做代码级定位（§5 仅含未验证的推测方向）。

1. 摘要（TL;DR）

从进行中的会话 fork 出新会话后，在新会话中提交任何新 prompt：

1. 实际被发送出去的不是用户刚提交的 prompt，而是 源会话（会话 1）的原始 prompt A —— A 作为一条新的用户消息在 fork 会话中被再次发送；
2. 用户真正提交的 prompt（B、C…）进入输入队列后 永远不会被派发，无论对话是否结束；
3. 再次 fork（会话 2 → 会话 3）时，同样的 A 又被重放一次，且 滞留队列随 fork 继承并累积（B、C 均滞留）。

结果：fork 功能无法用于"基于历史继续对话"——第一次提交必被旧 prompt 劫持，用户自己的 prompt 永远到不了模型；且每次重放都会向会话历史写入一条重复的 A 消息（上下文污染、token 浪费）。

2. 环境

项	值
DSH 版本	【0.1.5-rc.2】
客户端	Web GUI
关键操作	对 回复进行中（turn 未结束） 的会话执行 fork
prompt	A / B / C 为任意文本内容

3. 复现步骤与观察

1. 会话 1：发送 prompt A，此时 A 的回复正在进行中（turn 未结束）；
2. 在回复进行中，基于会话 1 的历史信息 fork 出会话 2；
3. 会话 2：发送 prompt B；
4. 从会话 2 fork 出会话 3：发送 prompt C。

实际观察

操作	实际发生
会话 2 发送 B	A 被再次发送（作为会话 2 的新用户消息）；B 进入队列
此后	无论对话是否结束，B 始终滞留队列，不被发送
会话 3 发送 C	A 再次被发送；B、C 均滞留队列

期望行为

• fork 只复制历史（只读快照），新会话不应自动发送任何内容；
• 在新会话发送 B 应立即执行 B；
• 不应存在永不派发的输入队列。

4. 行为规律（三次提交、两个 fork 代际）

1. 被重放的永远是 会话 1 的原始 prompt A，而不是 fork 源会话（会话 2）的最后一条 prompt——说明重放源是某种 随 fork 继承的滞留输入状态，而非最新历史；
2. 用户新提交的 prompt 全部入队且从不派发（B、C 在两个会话中均未执行）；
3. 滞留状态与队列 跨 fork 继承：会话 3 不仅重放 A，还继承了会话 2 中滞留的 B；
4. 复现与"fork 时 / 提交时源对话是否已结束"无关。

5. 疑似方向（未验证，仅供参考）

会话日志中用户输入以 agent/inbox/spliced（target: next-turn）入队、turn 开始消费后以 removedCount 移除。怀疑 fork 复制历史时把源会话的 待消费输入队列 / inbox 状态 一并继承：A 在会话 1 提交时的入队记录成为 fork 会话中的滞留种子，此后：

• fork 会话每次开始新 turn 都消费该滞留项（→ A 重放），但它从未被真正移除（→ 每次提交、每次 fork 都重现）；
• 新提交的 B / C 排在其后，而队列的派发条件永不到达（→ 永久滞留）。

6. 后果

1. fork 会话不可用：第一次提交被旧 prompt 劫持，用户 prompt 永远无法执行；
2. 历史污染：每次重放都写入一条重复的 A 用户消息并触发一轮对话——上下文重复、token 浪费，随 fork 代际反复发生；
3. 滞留队列跨 fork 累积（B、C…），无自愈、无清理入口；
4. 隐蔽性：现象表面上是"发错消息 / 消息一直转圈排队"，很难联想到 fork 继承的滞留输入。

7. 建议修复方向（供参考）

优先级	位置	建议
P0	fork 逻辑	fork 生成新会话时 丢弃 / 重置一切待消费输入状态（inbox / 输入队列 / 未派发 prompt），只复制已落盘历史
P0	输入派发	提交新 prompt 时若队列头是滞留的旧输入，应拒绝派发并显式告警，而不是静默重放
P1	队列派发	修复"队列永不派发"：对话结束后滞留输入应被正常发送或明确报错，不允许无限积压
P1	存量数据	对已产生滞留队列 / 重复 A 消息的会话提供清理或修复入口

---

[Bug][0.1.5-rc.x] A forked session replays the source session's old prompt (A) on new submissions; new prompts (B/C) are stuck in the input queue forever

Version baseline: DSH 【fill in, e.g. 0.1.5-rc.1】. This is a behavioral reproduction report without code-level analysis (§5-EN contains only an unverified hypothesis).

1. Summary (TL;DR)

After forking an in-progress session into a new one, submitting any new prompt in the forked session results in:

1. The message actually sent is not the prompt the user just submitted, but the source session's original prompt A — A is re-sent as a brand-new user message in the forked session;
2. The prompt the user actually submitted (B, C, …) enters the input queue and is never dispatched, regardless of whether the conversation has ended;
3. Forking again (session 2 → session 3) replays the same A once more, and the stuck queue is inherited and accumulates across forks (both B and C remain stuck).

Consequence: forking cannot be used to continue a conversation from its history — the first submission is hijacked by the stale prompt, the user's own prompt never reaches the model, and every replay writes a duplicate A message into the session history (context pollution, wasted tokens).

2. Environment

Item	Value
DSH version	【fill in】
Client	Web GUI
Key operation	forking a session while its reply is still in progress (turn not finished)
Prompts	A / B / C are arbitrary text

3. Reproduction and observations

1. Session 1: send prompt A; the reply is still streaming (turn unfinished);
2. While the reply is in progress, fork session 1's history into session 2;
3. Session 2: send prompt B;
4. Fork session 2 into session 3: send prompt C.

Observed

Action	What actually happens
Send B in session 2	A is re-sent (as a new user message in session 2); B enters the queue
Afterwards	regardless of whether the conversation ends, B stays queued and is never sent
Send C in session 3	A is re-sent again; B and C both stay queued

Expected

• A fork copies history only (a read-only snapshot); the new session must not send anything on its own;
• Sending B in the new session should execute B immediately;
• There must be no input queue that never dispatches.

4. Behavioral patterns (three submissions, two fork generations)

1. The replayed message is always session 1's original prompt A, never the fork source's (session 2's) latest prompt — so the replay source is some stale input state inherited by the fork, not the latest history;
2. Every newly submitted prompt is queued and never dispatched (neither B nor C ever executed in either session);
3. The stale state and the queue propagate across forks: session 3 not only replays A but also inherits B, stuck since session 2;
4. Reproduction is independent of whether the source conversation has ended by the time of forking / submitting.

5. Suspected direction (unverified, for reference only)

In the session log, user input is queued via agent/inbox/spliced (target: next-turn) and removed with removedCount once the turn consumes it. The suspicion is that forking inherits the source session's pending-input queue / inbox state: A's enqueue record from session 1 becomes a stale seed inside the forked session, after which:

• every new turn in the forked session consumes that stale item (→ A replay), but it is never truly removed (→ recurs on every submission and every fork);
• newly submitted B / C line up behind it while the queue's dispatch condition never arrives (→ stuck forever).

6. Impact

1. Forked sessions are unusable: the first submission is hijacked by the stale prompt; the user's prompts never execute;
2. History pollution: every replay writes a duplicate A user message and triggers a whole extra turn — duplicated context, wasted tokens, repeating across fork generations;
3. The stuck queue accumulates across forks (B, C, …) with no self-heal and no cleanup entry point;
4. Hard to diagnose: it surfaces as "wrong message sent / prompt stuck in queue", with no obvious link to fork-inherited stale input.

7. Suggested fix directions (for reference)

Priority	Location	Suggestion
P0	Fork logic	When a fork creates the new session, discard / reset all pending-input state (inbox / input queue / undispatched prompts); copy only the durable history
P0	Input dispatch	When a new prompt is submitted and the queue head is a stale old input, refuse to dispatch it and warn explicitly instead of silently replaying it
P1	Queue dispatch	Fix "the queue never dispatches": after a conversation ends, stuck inputs must either be sent normally or fail loudly; unbounded accumulation is not acceptable
P1	Existing data	Provide a cleanup/repair entry point for sessions that already carry stuck queues / duplicated A messages

[argszero]

源级复核：你观测到的行为与我读码得到的机制链一致，§5 的推测方向（fork 继承了待消费输入）基本正确

基线：本地 clone c291e7961a（= tag dsh-v0.1.5-rc.2）。以下行号是该树里的机械事实；我没有在你的环境复现，行为部分以你的报告为证据。

1. 完整机制链（每环都有源文件 + 行号）

1. 入队是持久事件，不是内存队列。 inbox 是 agent/inbox/spliced 事件上的投影（packages/core/agent-loop/src/inbox.ts:27-65 的 inboxProjectionDefinition，live 与 reconstruction 用同一份 fold）。followup() → send(msg,'next-turn',true) → inbox.splice(...) → session.append('agent/inbox/spliced', ...)（inbox.ts:230-238）。

2. 消费是另一次 splice，而且发生在 turn/start 之后。 turn() 先 append('turn/start')（agent-loop/src/agent.ts:278），然后才 preStep() → inbox.claim()（:244）；claim 以 discardRemoved=false 把消息从投影里摘掉（inbox.ts:111-116）。⇒ 已进入 turn 的在途输入，此刻在日志里仍然"pending"。

3. fork 的切点会跨过那个 turn/end。 session-controller/src/commands.ts:243-246：cut = boundary.seq + 1，然后跳过其后所有事件直到下一个 turn/start（while (cut < source.events.length && source.events[cut]?.type !== 'turn/start') cut++）；seed: source.events.slice(0, cut)、inheritedEventCount: cut（:263-264）。于是 A 那条插入事件被完整切进 seed。

4. 投影把整段日志（含继承前缀）重放一遍。 投影不按 inheritedEventCount 截断：cellFor() 惰性建 cell 时 buildCell(..., session.snapshotEvents()) 折整段日志（session-projection/src/index.ts:614-624），drive() 的 late build 也折 [0, event.seq)（:662-670）。

5. 子 Agent 第一个 turn 就把它 claim 走。 preStep('next-turn') 在 seed 里读到 pending 的 A，:375 以 surfaceOp:'append' 落一条真实 user/message —— 这就是你看到的"A 被再次发送"并再次进历史；turn/end 之后 :344 if (!this.inbox.hasPending) return false ⇒ 因为 B 还排在队列里（hasPending 为真），立刻又开一个 turn；而 :294 if (turnEnds && decision.messages.length === 0) break 只在"消息被摘空"时才让它退出。⇒ B 永远等不到属于自己的 turn 边界，于是永远不派发（正是你说的"滞留队列"）。每轮只取队首 1 条 next-turn（inbox.ts:113）也是这个后果的一部分。

2. 为什么它长这样：两处 fork 语义不对称，且其中一处被测试钉死

• live Session.fork() 是"停手"的：它以 turn/end（或显式 seq）为边界，边界落在开着的 turn 里直接抛 OPEN_TURN（core/session/src/index.ts:1254-1261），不会把在途输入切进去。
• GUI 走的 session/fork 是"滑动"的：commands.ts:244 那个前移循环（推测本意是让子会话正好停在下一个 turn 的起点，这样"在 fork 处继续对话"直接可用），代价就是把上一 turn 期间插入的 pending 输入一并带走。两处语义不同 ⇒ "按边界切"这件事本身不是全局契约。
• 这不是没人踩过的地方：packages/core/agent-loop/tests/inbox.spec.ts:129-155（projects inherited inbox events in a forked session）把"继承 pending"断言为期望行为 —— childInbox.nextTurn 等于父会话的 pending。⇒ 若把它当 bug 直接改，这条测试会变红；需要的是一次语义决策（见 §4），不是打补丁。

3. 报告里没有的三点

• "继承"与"重放"是两件事，"跨代累积"是另一件。 继承 = §1 第 3+4 步（机制）；重放成一条真实 user/message = agent.ts:375；而"再 fork 就再重放一次"来自 cut 的默认前移：子会话 fork 时其日志的最后事件正是继承来的 turn/end，前移循环把 seed 拉到日志末尾 ⇒ 整段（那条 pending 插入 + 子会话自己的 A 回放）一并被下一个世代继承。你测到的"三次提交、两个 fork 世代"正是这条。
• 顺手排除一个看起来对的方向：isSeeded 修不了它。 seed 整体不经过 session/event 发布（core/session/src/index.ts:477-479 注释原文 "constructor seeds do not emit"）。所以读投影时若只看 isSeeded 就跳过前缀，会把真实历史（含子会话自己落下的那条 user/message）一起漏掉 —— 比原缺陷更糟。
• 客户端侧可以排除，但需要一个判别式。 ui-workspace/src/client/navigation.ts:147-151 的 forkSession() 只做 fork() + openSession(childId)，不把 composer draft 交给子会话（draft 传递只发生在 selectWorkspace 路径，ui-conversation/src/client/apply.ts:259-279）⇒ 若那条 A 其实来自客户端 draft，会走的是另一条渠道。判别只需一步：取那条被重放的 user/message 事件的 seq，与子会话的 inheritedEventCount（= 头部行 seedLength）比较 —— 落在之内 = 继承（core 面），落在之外 = 客户端面。你在 §4 已把 A 限定为"已提交的 prompt"，与日志侧一致。

4. P0 的两种修法（我更倾向乙，因为它不动被钉死的契约）

• 甲：fork 时不把 pending 输入切进 seed。 把 cut 收到"最后一个 turn/end"（两种 fork 都处理同一形状），代价 = 更新 inbox.spec.ts:129-155 这条契约。
• 乙：保留继承的 pending，但改变队列的派发优先级。 让"用户新提交的消息"永远先于"继承来的滞留项"被 claim，或对继承来的 next-turn 打标（例如只在子会话首次提交之前可消费）。这不改被测试钉死的"C 面继承"断言，但需要决定继承项与用户新输入的相对顺序语义。

我认为真正的决策点是"被 fork 继承的 pending 该不该随子会话自动派发"，而不是切点本身 —— 这需要维护者拍板，所以我把它作为讨论留在这里，而不是断言某个补丁对。

5. 插件可挂载面判定（我的插件线配额）

结论：缺口落在 core 面，插件只能做受害者侧规避，修不了。

• Agent.inbox 是公开契约（core/agent/src/runtime-types.ts:170，接口 :48-100），所以插件能读某个 agent 的 pending。
• 但没有插件缝能改变 fork 产出的事件序列：session/fork 是 gateway RPC 的内部实现（api/session-controller/src/commands.ts:202-292），其 seed / inheritedEventCount 由 agents.create() 的构造参数决定（core/agent-loop/src/index.ts:740-760），两者都不经过 cordis 事件或 waterfall。
• 插件能做的规避很小且严格更差：监听 agent/created，对 header.isSeeded === true 且 inbox.nextTurn 非空的会话执行 inbox.clear() —— 但 clear() 会连用户真正想发的 B 一起丢掉（inbox.ts:99-103 清空两张表）。⇒ 归为 upstream-fix 候选（P0 在 fork 的 seed 构造 / 队列语义），我不为它发插件。

6. 边界

• 全部结论基于 c291e7961a 读码；0.1.5-rc.2 与该 commit 是否为同一版本我未核对，若你手边有 dsh --version 的 commit 我可以逐条对齐。
• §2 关于 cut 前移"本意"的一句是推测（该处无注释），其余行号/谓词主张均为该树中的事实。

---

EN TL;DR — Your §5 hypothesis is essentially right, and here is the exact chain on c291e7961a: the inbox is a projection over durable agent/inbox/spliced events (agent-loop/src/inbox.ts:27-65); turn() appends turn/start before inbox.claim() (agent.ts:278 vs :244), so input that arrived during an in-flight turn is still pending in the log; and fork's cut advances past the last turn/end to the next turn/start (session-controller/src/commands.ts:243-246), so the seed carries that pending insert; projections fold the whole log including the inherited prefix (session-projection/src/index.ts:614-624). The child claims A, writes a real user/message (agent.ts:375), and :344 reopens another turn while B is still queued — B never gets a turn boundary of its own. Note tests/inbox.spec.ts:129-155 pins inherited pending input as expected, so this needs a semantics decision, not a patch. No plugin can change fork's seed (session/fork is gateway-internal; seed/inheritedEventCount are agents.create() constructor args), so I'm filing it as an upstream-fix candidate rather than shipping a plugin that would trade a replay for a silent dropped message.

[lgzzzz]

#6141

一样的问题

[joker-charles]

fix-session-fork-cut.tar.gz
文件内修复脚本

[shengyvself]

补充：服务器侧独立复现 + 真实日志量化 + 本地已验证的最小补丁

基线：@deepseek-ai/dsh 0.1.5-rc.2；dsh-api-session-controller 0.1.5-rc.2。该 lib/index.js 与 0.1.5-rc.1 字节完全相同（md5 2443ac0c1184472ca09d064a38a8e344），且上游 master 的 packages/api/session-controller/src/commands.ts 仍是同一段循环 → 截至 2026-09-13 官方未修。本文不是重复报告，是补上「机制 + 真实数据量化 + 可比较的补丁」。

1. 机制（与 @argszero 的源码链一致，这里补上「被中断那一轮」为何必中）

fork() 取种子时：

const boundary = ...   // atSeq 之后第一个 turn/end，即用户点「分支」的那一轮
let cut = SessionLogOffset(boundary.seq + 1)
while (cut < source.events.length && source.events[cut]?.type !== "turn/start") cut = SessionLogOffset(cut + 1)
seed = source.events.slice(0, cut)

该 while 把 boundary 之后、下一个 turn/start 之前的全部事件扫进种子，其中包括下一轮 prompt 的 agent/inbox/spliced 插入事件。DSH 每条用户消息都是「先入 inbox → turn/start → consume(inbox)」，而 consume 在 turn/start 之后，不在种子里。子会话重放种子即重建出一个非空待发队列 → 第一次提交先消费它。

被中断那一轮正是高发场景：分支点在上一轮的 turn/end，被中断轮的 prompt 插入紧贴在它的 turn/start 之前，必然被扫入。

2. 真实日志证据（本机 Information 工作区）

父 session-f4859ede-f7a1-456b-bdc6-647973622446 → 子 session-65dcab50-6954-4113-bd2d-6b0ea804893e

时间(2026-09-13)	父 seq	事件
10:59:02	775	turn 7 turn/end ← 分支点
11:00:07	776	agent/inbox/spliced 插入 A
11:00:38	780/783	turn 8 开始，A 作为 user/message 已发出
11:00:41	787	turn 8 turn/end aborted(user) ← 用户中断
11:01:00	—	fork：旧切点 cut=780，种子含 seq776/779 → 子会话继承队列 [A, B]
11:01:30	子 782/786	新 prompt 进 index 2；队列头 A 被当成本轮 user/message 重发

3. 量化：不是偶发，是普遍现象

对本机全部 61 个会话日志（~/.dsh/sessions///session.v3.jsonl.zstd）扫描每个 turn/end 锚点：

• 锚点 640 个；旧切点≠新切点的 603 个；
• 累计被错误继承的待发消息 596 条。

⇒「在非末轮 fork 必带上下一轮 prompt」几乎每次发生。

4. 本地已验证补丁（最小改动，只改种子截断点）

  let cut = SessionLogOffset(boundary.seq + 1);
- while (cut < source.events.length && source.events[cut]?.type !== "turn/start") cut = SessionLogOffset(cut + 1);
+ // 种子同样必须在 agent/inbox/spliced 之前截断，而不仅仅在下一个 turn/start 之前
+ while (cut < source.events.length && source.events[cut]?.type !== "turn/start"
+        && source.events[cut]?.type !== "agent/inbox/spliced") cut = SessionLogOffset(cut + 1);

理由：种子本应是 completed-turn prefix，boundary 之后的事件不该进入分支；其中只有 agent/inbox/spliced 是活状态（turn 配对 / compaction 括号 / model/selection 等区间事件保留，避免误伤）。无待发 inbox 变更时与官方行为逐字节一致。

验证：同一条 atSeq → 旧 cut=780 得继承队列 [A, B]；新 cut=776 得 []；node --check 通过。

5. 一点备注

@joker-charles 的 fix-session-fork-cut.tar.gz 我在服务器侧下载超时未能核对；欢迎比对切点是否一致。若官方修复了此处，本补丁会撤下以免双重修复冲突。

（本地运维记录：PATCH-record-20260913-fork-seed-inbox.md）

[argszero]

A correction to one line of the earlier source-level note, now that I have re-checked it against the published artifacts.

"上游 master 的 packages/api/session-controller/src/commands.ts 仍是同一段循环 → 截至 2026-09-13 官方未修" — the released-version half is right, the master half is not. The advance loop was removed on 2026-09-11, two days before that comment:

• master today: packages/api/session-controller/src/commands.ts:243 is const cut = SessionLogOffset(boundary.seq + 1);, with the boundary chosen as the first turn/end at or after the anchor (:228-231). No while (cut … !== 'turn/start') cut++.
• the change is f74d625e5a (merge of PR [Contribution] examples: add computer-use MCP interoperability example (ready to cherry-pick) #4001, branch fix/session-fork-boundary), written up as .agents/notes/implemented/bug-fix/2026-09-11-session-controller-fork-turn-cut.md.
• first release containing it: 0.1.6-alpha.1. I read the installed artifacts rather than the tree: dsh-api-session-controller@0.1.5-alpha.1, 0.1.5-alpha.2 and 0.1.5-rc.2 all still carry while (cut < source.events.length && source.events[cut]?.type !== "turn/start") cut = SessionLogOffset(cut + 1); (lib/index.js:685 in the 0.1.5 line), while 0.1.6-alpha.1 has only const cut = SessionLogOffset(boundary.seq + 1); (lib/index.js:684).

So for anyone still on the 0.1.5 line the note's analysis and patch remain exactly right; on 0.1.6-alpha.1 and later the reported shape no longer occurs.

What the decision deliberately leaves alone, from the note itself: "Events already inside the selected prefix retain their ordinary replay semantics; this decision does not redefine pending input inserted before the selected closing event." Input already pending inside the selected turn — a followup() issued during it, or a steer()/inject() parked in next-step when it ended — still replays into the child on every line including 0.1.6.

I wrote the full per-line picture up on #7118 (same mechanism, reported against 0.1.5-alpha.2), including one cross-line correction that matters for the client-side workaround: the inbox reconstructs from session.ownEvents() on 0.1.2-rc.1/0.1.3-alpha.2 (so a seeded child's inbox is empty there and the phantom never appears) and from the whole session from 0.1.5 on — so a compensating removal has to act on the intersection of "what the child's inbox holds" and "what the copied prefix explains", never on the prefix fold alone. That is what @argszero/cordis-plugin-fork-inbox-guard does.