fork 之后，fork 前那条消息仍在排队，但界面上不显示

[PC2005-cloud]

复现步骤

1. 发送 P1，等待生成结束。
2. 发送 P2，生成中，结果不满意。
3. 点「停止」中止生成。
4. 在 P1 所在的已完成消息上执行「fork」。
5. 新会话打开，转录显示正常（不含 P2）。
6. 不刷新页面，直接输入 P3 并发送。

实际结果

• 先被处理的是 P2（fork 之前那条），我输入的 P3 进入排队。
• 若第 6 步不发送、只刷新页面：P2 以「排队中」的形态出现。

我期望的

fork 出的新会话里不应该再看到、也不应该继续优先处理 fork 之前那条消息——我 fork 的目的就是不要它。如果它确实需要保留，至少应该立刻可见、可取消，而不是必须刷新才出现、并且已经挡在我前面。

对体验的影响

• 不刷新完全看不出来 P2 还在排队，用户会以为 fork 已经把它丢掉了。
• 新消息被卡在队列后面，必须刷新并手动处理才能继续，与 fork 的使用方式直接冲突。

环境

• dsh 0.1.5-rc.1（dsh --version）
• Windows / Node v24.19.0
• 入口 dsh web → http://127.0.0.1:8080，profile：web

---

我只记录可观察的现象，不确定这是预期行为还是缺陷，交由你们判断；如果是我对 fork 的语义理解有误，也请指正。

[PerryLink]

服务器侧语义已核实（master c291e79，2026-09-13）：fork 只裁剪转录，不
touch 队列。

• packages/api/session-controller/src/commands.ts:202-295：
  • 边界 = 源会话最后一个 turn/end（:226-242；没有已完成回合直接报
    session/fork-unavailable）；
  • 裁剪从 boundary.seq+1 起，越过非 turn/start 的事件（:243-246）；
  • 子会话 seed = source.events.slice(0, cut)（:263），meta 带
    parentSession / isSeeded / cwd / agentPreset（:266-271）。
    已提交但尚未落盘的排队消息不在转录里，fork 天然「看不见」它——所以
    fork 本身没有丢弃 P2，也没有义务丢弃：它从未成为转录的一部分。

你观察到的顺序（P2 先于 P3 被处理）来自客户端队列：被停止的 P2 是
placement==='queued' 的提交（packages/client/ui-conversation：
QueueDock.tsx:92-97 渲染排队行；InputBar.tsx:298 把仍挂起的排队消息导向
运行中的回合）。fork 后客户端把活动会话切到子会话，这条排队提交没有随
fork 清除，于是先于 P3 受理。客户端这条链我未在本机完整复现，标注为
推断（未验证）；服务器侧语义为已验证。

结论：不是服务器 bug，是「fork 与客户端排队队列不联动」的真实 UX 缺口
——fork 的语义只覆盖转录，队列是另一份状态。你的期望（排队消息立刻
可见、可取消）完全合理。

立即可用规避：fork 后先刷新页面再输入；或 fork 前手动清空/取消排队消息。
建议把本帖转成 feature request：fork 时丢弃源会话的排队消息，或在子会话
里显式展示它们。

[000wbh000]

同样发现此问题，我这边即使省略第三步也能复现。

[keg1255]

感谢，在你这里找到了临时的解决思路。刷新页面把队列删除再发送