[Bug]会话创建在播种（seed）阶段失败时会留下静默空壳，UI 表现为「点击新建无反应」

[BeiWay1145]

概述

DSH 在会话初始化播种阶段失败时，会留下一个已落盘、已进入列表、却没有任何错误提示的半成品会话。用户侧看到的现象是「点击新建会话没有反应」。

这个 bug 有两个层面：

1. 静默失败——一个失败的创建不该留下看起来成功的产物，也不该不报错；
2. 数据残留——每次失败的点击都会累积一个 4 事件的空壳，且永不自愈。

---

环境

组件	版本
DSH Desktop	2.0.17
@deepseek-ai/dsh	0.2.0-rc.2
dsh-session	0.2.0-rc.2
cordis	4.0.4
平台	Windows 11（Modern Standby）

---

复现现象

在一次实例运行期间（未重启），连续创建会话时出现：

session-560c0c0a-...  createdAt=04:48:58  4 事件  323B  ← 空壳
session-0bd30cab-...  createdAt=04:49:04  4 事件  323B  ← 空壳
session-c66f4539-...  createdAt=04:49:06  4 事件  322B  ← 空壳
session-9b56774c-...  createdAt=04:49:11  4 事件  318B  ← 空壳
session-909691c7-...  createdAt=04:49:12  4 事件  320B  ← 空壳
session-bd0883fe-...  createdAt=04:49:13  4 事件  322B  ← 空壳
session-2c90bad0-...  createdAt=04:50:20  4 事件  323B  ← 空壳

关键：同一时段、同一工作区也有成功创建（b4883ca1，252 事件，正常）。所以这不是配置问题，而是创建时刻的瞬时状态失效。

故障横跨 4 个工作区

工作区	空壳数
D:\学习	7
D:\VibeCoding\project	1
D:\VibeCoding\project\平板投屏	1
D:\VibeCoding\project\FanR_Plugin	1

---

根因：session/end-seed 从未写入

对比两类会话的完整事件序列。

失败（空壳）——停在 seq=2：

{"type":"session","version":4,"id":"session-2c90bad0-...","cwd":"D:\\学习","isSeeded":false,"agentPreset":"ptc"}
{"type":"permission/preset","seq":0,...}
{"type":"sandbox/mode","seq":1,...}
{"type":"approval/policy","seq":2,...}

成功（对照）——seq=3 即播种标记：

{"type":"approval/policy","seq":2,...}
{"type":"session/end-seed","seq":3,...}     ← 空壳缺失的正是这一条
{"type":"agent/inbox/spliced","seq":4,...}

写入逻辑位于 dsh-session/lib/index.js：

if (seed !== void 0 && mode === "snapshot" && this.header.isSeeded && !markedSeed) {
    this.append("session/end-seed", { inherited: true });
}
else if (seed !== void 0 && !(mode === "snapshot" && this.header.isSeeded)
         && this.log.at(-1)?.type !== "session/end-seed") {
    this.append("session/end-seed", {});
}

空壳的 isSeeded 为 false，因此走 else if 分支。该分支未命中只有一种可能：seed === void 0。

也就是说，Session.create(id, seed, header, ...) 调用时 seed 参数未被传入。会话对象、日志句柄、以及前三条基础事件都已建立并落盘，唯独播种这一步没有发生。

---

一个有力的旁证

b4883ca1（学习工作区，04:59:46 创建，252 事件）虽然诞生于故障期，却是正常的——它的 end-seed 写于 05:00:24，即用户重启之后。

说明：重启时内核把它作为活跃会话重新初始化，补上了当初缺失的播种标记。

而失败者之所以永久是空壳，仅仅因为重启时没有恢复它们。 这既证明了「重启即恢复」的因果关系，也说明故障的本质是创建瞬间的一次性失效，而非数据损坏。

---

触发条件（高度疑似）

本机系统日志显示：

10-10 23:56:02   Kernel-Power Id=42   系统正在进入睡眠状态
        ... 4 小时 49 分 ...
10-11 04:45:23   Kernel-Power Id=107  系统已从睡眠状态恢复

紧接着在宿主日志中捕获到一条跨越整段睡眠的 RPC：

2026-10-11 04:45:21.531 [E] [agents-anywhere-runtime] event=rpc.failed {
  "method": "runtime.getCapabilities",
  "elapsedMs": 17366025,          // = 4.824 小时
  "errorType": "AbortError"
}

17366025 ms 反推发起时刻为 23:55:55——恰好卡在睡眠前 7 秒。随后是 ECONNRESET 的连锁。

故障窗口（04:48:58 起）正好落在系统唤醒（04:45:23）之后约 3.5 分钟内。

推测：进程从 Modern Standby 唤醒后，内部异步链与定时器处于不一致状态，会话创建路径正撞在这个窗口里。

---

期望行为

1. 创建即原子——播种失败时不应留下半成品会话（回滚或标记为 failed）；
2. 失败要可见——UI 应明确告知创建失败，而不是让用户以为「点了没反应」；
3. 自愈——启动时的会话/工作区校准应能识别并清理这类无法使用的空壳（目前 post-boot workspace reconcile 只处理 sessionIds 与磁盘目录的差异，不检查播种完整性）。

---

附：另一个独立（无关）的缺陷

排查过程中发现一个与本 bug 无关、但同样值得修的问题：

dsh-session-manager v0.4.11 的 coldSnapshot 调用签名不匹配。

内核定义（dsh-session-projection-cache/lib/index.js:285）为 3 参数：

coldSnapshot(meta, inheritedEventCount, events) {
    const identity = identityOf(meta, inheritedEventCount);
    ... SessionLogOffset(0) ...
}

而插件只传了 1 个字符串（dsh-session-manager/lib/index.js:1062）：

await cache.coldSnapshot(header.id);

导致 SessionLogOffset(undefined) 抛错：

TypeError: SessionLogOffset must be a non-negative safe integer, got undefined

每次启动都会产生成百上千条（本机 10-08 单日 9580 条）。由于调用点包在 try/catch 中，仅记录 warn、随后 re-folded 0 rows，不影响功能，但持续污染日志。这属于插件侧未跟进内核 API 变更。

---

备注

本次共清理 10 个空壳会话目录及其投影缓存条目（已备份）。如需任何原始日志、事件转储或完整时间线，我可以随时补充。

感谢维护者的时间。

[PerryLink]

请先别再删了 —— 那些不是残骸，是健康会话。

我把你贴的代码、事件序列和那份缓存行都核了一遍：你取证的部分是对的，但结论反了。 session/end-seed 不是"播种成功"标记，而是「继承 / 恢复前缀边界」标记 —— 正常新建的会话本来就不该有它。

1. end-seed 的真实语义

packages/core/session/src/index.ts:694-698 你贴得逐字正确：

if (seed !== undefined && mode === 'snapshot' && this.header.isSeeded && !markedSeed) {
  this.append('session/end-seed', { inherited: true })
} else if (seed !== undefined && !(mode === 'snapshot' && this.header.isSeeded)
           && this.log.at(-1)?.type !== 'session/end-seed') {
  this.append('session/end-seed', {})
}

两个分支都以 seed !== undefined 为前提。 而 web/desktop 的「新建会话」正路径根本不传 seed：

• packages/api/session-controller/src/agent.ts:486-494 → return (await this.ctx.agents.create({ sessionId, agentOptions: …, meta: { cwd, … }, setup: composition.setup })).agent —— 没有 seed
• packages/core/agent-loop/src/index.ts:751-755 → ...options.seed === undefined ? {} : { seed: options.seed }
• packages/core/session/src/index.ts:1171,1184 → const seed = options?.seed / return Session.create(sessionId, seed, header, …)

⇒ seed === undefined ⇒ 两个分支都不进入 ⇒ 正常新建会话天然没有 session/end-seed。

2. ⭐ 你引为铁证的那条，恰恰证明了另一半

你写"重启后 b4883ca1 的 end-seed 写在 05:00:24"。那正是 resume 路径写的：

• packages/core/agent-loop/src/index.ts:893-898 → preparation = SessionPreparation.create(this.runtime.ctx.sessions.prepare(id, { seed: [...persisted, ...closers], meta: structuredClone(handle.header), … }))
• packages/core/session/src/index.ts:608-624（fromRestore）→ mode = eventState，不是 'snapshot' ⇒ 落到 :696 的 else if ⇒ 在持久化日志尾部追加 session/end-seed {}

⇒ 它是重启时补的恢复边界，与"当初播种是否成功"无关。所以"重启后才出现"不是"补上缺失的标记"，而是它本来就该在那时候出现。

3. 那 4 事件 / 323 B 是成功创建的完整形态

packages/interaction/permission-presets/src/index.ts:245 → ctx.on('session/created', (session) => {，:437-443：

if (preset === null && sandbox === null && approval === null && !seeded) {
  const name = this.defaultPreset
  const spec = this.resolve(name)
  session.append('permission/preset', { preset: name })
  setSandboxMode(session, spec.sandbox)
  setApprovalPolicy(session, spec.approval)
  return
}

⇒ 恰好就是你看到的那三行外加头部 = 4 事件。这是 session/created 上的标准预置写入，不是失败残渣。

建议马上停止按"残骸"清理：你已经删掉 10 个备份，那些备份可能包含真实历史（哪怕只是策略事件与 header，也带着标题、时间线与 metadata）。

4. 宿主层不会静默失败

packages/api/session-controller/src/commands.ts:533-556：

private rejectCreation(sessionId: SessionId, error: unknown): never {
  …
  throw new RemoteError('gateway/internal', `failed to create session "${sessionId}": ${String(error)}`, {})
}

返回类型是 never ⇒ 创建失败一律抛出结构化错误，"静默失败"在宿主层不成立。另外 packages/core/agent-loop/src/index.ts:704-710 的 JSDoc 明确写了构造期语义："a failed or cancelled validation or setup closes an unmaterialized handle and leaves no stored residue — the same id can be created again." ⇒ 「创建即原子」已经实现。

5. 你的 coldSnapshot 附注是对的，值得单独转出去

packages/session/session-projection-cache/src/index.ts:287-291 → coldSnapshot(meta: SessionHeader, inheritedEventCount: SessionLogOffset, events: readonly SessionEvent[]): ProjectionSnapshot —— 确实是三参数。

但 dsh-session-manager 不在本仓（dsh-session-manager 与 session-manager 两个 pattern 各 0 命中，已复核）。⇒ 那是第三方插件未跟进内核签名，内核侧没错。建议把这条直接发给该插件作者。

6. 「点击新建无反应」这条我没能证实，需要你的日志

代码里唯一能找到的"会话已创建成功但 UI 无反应"的机制是 commands.ts:131-140 的 workspace.attachSession 失败路径 —— 那时会话已经 create 并 publish（4 事件已落盘），但 RPC 抛 session/workspace-attach-failed。

这是假设，不是结论。 请贴 04:48–04:50 窗口的 host 日志（搜 session.create / attachSession）。在拿到它之前，我不建议把这个现象写进报告标题。

7. 一条边界

你 header 的 "version":4 与 SESSION_FORMAT_VERSION = 4（packages/core/session/src/types.ts:89）一致 ⇒ 版本没过期，上面每一条对你的构建都成立。

如果你要的其实是"空白会话不该长期堆积"这个诉求 —— 那是合理的，但要注意：blank === true 且从未 resume 正是"用户开了新会话还没说话"的常态，不应自动删除。可行的方向是让它可见/可甄别，而不是清掉。