会话删除器 Gty2408/dsh-session-eraser

dsh-session-eraser

从 DSH 侧边栏删除会话，永久移除它存储的日志和工作区记账。

安装

dsh plugin --profile desktop add dsh-session-eraser

然后重启 DSH。这条命令会安装包，通过 dsh.bundle.patch 机制应用本包的 cordis.patch.yml，并把包加入配置档的 bundle 列表——不用手动改配置。

没有 dsh 命令行时，把包放进配置档的 node_modules，再在配置档的 cordis.patch.yml 里加上：

- insert:
- id: dsh-session-eraser
name: dsh-session-eraser

它做什么

在侧边栏每个会话行上加一个 Delete session 入口，共两处：

- 行内的 ... 菜单，位于自带的 Archive 行下方；
- 悬停时显示在行内其他操作旁边的垃圾桶按钮。

两个入口都会打开确认对话框。确认后从磁盘移除会话存储的产物，从工作区解绑，并通知所有已连接的客户端该会话已消失，于是这一行立刻消失。

打开会话的保护

删除当前在主面板中打开的会话会被拒绝。

这是有意为之。工作区 UI 能协调已归档的当前选中项，却没有应对当前会话被移除的路径：它不暴露公开的关闭/离开 API，而 openSession 只能替换。因此删除打开的会话会让主面板指向一个已不存在的会话，输入框静默禁用，且无法返回。

所以保护在四处拒绝：

| 入口 | 会话打开时的行为 |
| ... 菜单行 | 渲染为禁用，标签为 Delete session (currently open) |
| 悬停垃圾桶按钮 | 完全不渲染 |
| 对话框确认按钮 | 禁用，并附内联说明 |
| 对话框确认操作 | 重新检查保留状态并拒绝 |

悬停按钮选择不渲染而非禁用，是因为原生禁用的按钮不触发指针事件，它的 tooltip 永远无法解释拒绝原因——而且行操作槽位自己的目录规定：操作不适用于该行时就不渲染。

宿主路由

POST /api/session.delete

// request
{ "sessionId": "session-04e8f277-…" }

// 200
{ "ok": true, "status": "deleted", "live": true, "detached": true, "removed": 1 }

| 状态 | 响应体 | 含义 |
| 200 | { ok: true, … } | 已删除，并验证已从磁盘消失 |
| 400 | { error: "…" } | 请求体格式错误，或 sessionId 缺失/无效 |
| 404 | { error: "session not found" } | 没有存储的产物，也没有活动会话 |
| 500 | { error: "…" } | 意外失败，或产物在移除后仍然存在 |

路由绝不报告它无法验证的成功。rm 在 Windows 上会因真实原因失败——文件被锁定或 deny-ACL 会抛 EPERM/EBUSY——所以移除产物后，插件会重新检查路径，若还有任何存活下来，工作区记账保持原样，这样侧边栏仍会显示那个实际仍然存在的会话。

这条路由通过连接的 Fetch 处理器提供，因此它和其他 /api 一样位于同一道认证门之后，只有来自受信任来源才能访问。

删除顺序

Host 没有会话擦除 API，所以删除由公开组件按特定顺序组合而成：

1. workspaces.stopSessionActivity(sessionId) —— 请求停止该会话。
2. sessions.liveEntryFor(live) + sessions.detachEntered(entry) —— 分离活动会话，这也会派发 session/disposed。
3. 让写入器落定。持久化拆除的 writer.close() 不会 await，而 appendLines 每批都用 open(path, "a") 打开日志 —— 这会重新创建已删除的目录 —— 所以输掉竞态的排空会复活日志。有两种机制覆盖这一点：
- settleWriter(...) 直接汇合进行中的关闭。它读取一个未文档化的内部字段（persistence.tracker.openHandles），一旦该字段被改名就会失败开放，所以它只是优化，不是保证。
- persistence.flush() —— 公开的持久性屏障 —— 排空每个活跃写句柄，并发关闭中的句柄也算作已刷新。
- 当两者都无法 await 时，删除会被扣留一个有界的落定窗口，重新删除任何被迟到排空恢复的东西。
4. 删除每个定位到的产物，然后验证它已消失。任何幸存下来的都报告为失败，而不是成功。
5. 重新索引工作区，清除会话的归档与固定条目，并将其从所属实体上分离。
6. ctx.emit("api-session/removed", sessionId) —— 这样冷会话会立即从其他客户端消失，而不只是在下一次列表刷新时。

第 5 步的归档/固定清理很重要，因为这些是注册表全局的 id 列表：删除会话会移除它们所指向的行，所以 UI 里再也不会提供取消归档或取消固定的选项 —— 那个 id 会永久悬空。两个删除 API 都按设计跳过会话存在性检查（「会话已消失的条目仍能解析」），而这正是本例的情况。

所有者在重新索引之前捕获，因为 entity.sessionIds 由规范 cwd 头索引实时过滤，重新索引会剪掉该 id。

存储布局

产物位于 ~/.dsh/sessions/<encoded-project-dir>/<encoded-id>/ 下，日志在 session.v4.jsonl.zstd。插件精确镜像后端的 encodeSegment，所以恶意的 sessionId（穿越序列、绝对路径、分隔符）只能解析到根目录内它自己转义后的目录。test/host-traversal.test.mjs 埋下金丝雀并证明了这一点。

测试

node test/run.mjs

host- 套件是封闭的 —— 它们使用一次性持久化根，并对路由触及的服务打桩。live- 套件与运行中的应用通信（DSH_TEST_ORIGIN，默认 http://127.0.0.1:19387），连不上就自动跳过。

| 套件 | 覆盖内容 |
| host-route.test.mjs | 冷会话删除、状态码、产物清理 |
| host-live.test.mjs | 活跃会话分支：停止、分离、结算、属主分离 |
| host-writer-race.test.mjs | 迟到的写入方排空后，不得让日志复活 |
| host-race-control.test.mjs | 同样的竞态在没有修复时必须失败——证明修复是承重的 |
| host-internals-change.test.mjs | tracker.openHandles 缺失时，删除依然正确 |
| host-bookkeeping.test.mjs | 会话删除后，不留悬空的归档/固定条目 |
| host-partial-failure.test.mjs | 拒绝 ACL 抛出的真实 EPERM 会被上报，而不是被吞掉 |
| host-traversal.test.mjs | 恶意 id 只能解析到转义后的根内目录 |
| client-guard.test.mjs | 两个入口和对话框，包括打开会话守卫 |
| live-end-to-end.test.mjs | 对运行中的应用发起带认证的 HTTP 请求，包括一次真实删除 |
| live-bundle.test.mjs | 运行中的应用在声明的修订版本上提供带守卫的客户端 bundle |

live-* 用 ~/.dsh/.credentials.yaml 里的浏览器会话签名密钥自行签发认证 cookie；不涉及浏览器，也不用 cookie jar。

已知限制

- 附件不会被删除。 删除只移除会话日志和它的工作区记账；会话在磁盘上引用过的文件会留在原地（它们的引用随日志一起消失）。要删掉这些文件，就得知道会话实际创建了哪些文件，而不只是读过哪些。
- 打开会话守卫只在客户端。 Host 没有视图状态的概念——mainView 的保留逻辑在浏览器里——所以手工构造一个针对当前打开会话的 POST /api/session.delete 不会被拒绝。该路由在常规认证门之后，因此只有用户自己已认证的客户端才能触达，而随附的 UI 从不发送它。
- settleWriter 读取了内部字段。 persistence.tracker.openHandles 不属于文档化的接缝。插件把它当作优化：就算它消失，公开的 flush() 屏障和有界结算窗口仍能产生正确的删除，host-internals-change.test.mjs 锁定了这一点。
- 删除不是事务性的。 如果进程在移除和重建索引之间挂掉，产物已经没了，但工作区记账可能仍列出该会话，直到下一次索引重建才会对账。

目录结构

lib/index.js Host 半边：删除路由和删除序列 lib/client.js 浏览器半边：菜单行、悬停按钮、确认对话框 cordis.patch.yml 注册 bundle test/ 测试套件（见上）