[Bug 报告] 外置盘离线时启动 DSH 后，一次工作区写入就会把旧会话永久剔除出工作区登记（落入「未分组」）

[miaoxingyunduo]

环境

• DSH 0.2.0-rc.2（Windows 11，Web GUI）
• 工作区位于 NTFS 移动硬盘（E:\...），~\.dsh 在系统盘

现象

工作区建在移动硬盘上。DSH 在硬盘未挂载时启动过一次；之后（硬盘已重新接上）在同一工作区新建了一条会话，侧栏里该工作区原有的那条会话就滑进了「未分组」。此后无论硬盘在不在线、重启多少次都不会自动归位——~\.dsh\storages\workspace.json 里该工作区的 sessionIds 已经把旧会话永久丢掉了。

根因（引自安装包 resources/app.asar 打包产物，符号名保留）

工作区归属 = 注册表记录里的 sessionIds，再叠加一层按「会话 cwd 规范化路径」做的运行时过滤。问题在于这两处共用一个只在启动时全量重建的路径缓存 sessionPaths：

1. 启动索引：cwd 一时解析不到，会话就被记为无效

async indexHeader(header) {
  ...
  const path = await realpathNormalize(header.cwd);
  if (!(await stat(path)).isDirectory()) {
    this.invalidSessionPaths.set(header.id, `cwd '${header.cwd}' is not a directory`);
    return;                                   // ← sessionPaths 里没有它
  }
  this.sessionPaths.set(header.id, path);
}

启动时外置盘离线 → stat 失败 → 该会话只进 invalidSessionPaths。运行期只有活跃会话会被补录（indexLiveSessions），全量重索引只发生在启动：

if (!this.state.initialized) { const headers = await this.listStoredHeaders(); await this.replaceHeaderIndex(headers); await this.bootstrap(headers); }
else if (this.table.size > 0) await this.replaceHeaderIndex(await this.listStoredHeaders());
await this.indexLiveSessions();

2. 每次写工作区记录都会修剪成员，并立即落盘

mutate(fn) {
  ...
  changed.sessionIds = changed.sessionIds.filter((id) => this.host.sessionPath(id) === changed.path);
  ...
}

显示过滤是同一套逻辑：

get sessionIds() { return this.record.sessionIds.filter((id) => this.host.sessionPath(id) === this.record.path); }

而 sessionPath(id) 就是 sessionPaths.get(id)。于是：「启动时盘没插上」的会话，在该工作区下一次任何写入（新建会话 attach、改名、排序……）时被静默永久剔除；显示层则是缓存未命中就直接不进分组——这就是「未分组」的来源。

新会话自己安然无恙，因为 attach 时走了 rememberSessionPath：attachSession() 对新会话做 realpath 校验（此刻盘已挂上，通过）并记下它的路径，随后那次 mutate 修剪只把「记不得路径」的旧会话踢掉。bootstrap()（按 cwd 归并历史会话）只在 !state.initialized 时运行，重启不能自愈。

复现步骤（确定性）

1. 在外置盘 E:\WS 新建工作区，在其中开一条会话 S1 → 正常分组；
2. 完全退出 DSH；拔掉外置盘；启动 DSH（S1 的 cwd 解析失败，进入 invalidSessionPaths）；
3. 插回外置盘（不重启），在同一工作区新建会话 S2；
4. S1 被从该工作区 sessionIds 中永久剔除并落盘，滑入「未分组」；重启不恢复。

期望行为

• 「暂时解析不到 cwd」不等于「不属于该工作区」：修剪只应剔除 header 缺失或规范化 cwd 确实不等于记录 path 的会话；解析失败时应保留成员，或跳过该成员的过滤并标注「目录暂不可用」；
• 显示过滤同理：cwd 解析失败时成员应留在分组内（可置灰），而不是移出；
• reportFilteredCandidates() 目前只写日志；这种会写盘的丢失建议至少给出可见提示和恢复入口。

影响

• 归属丢失静默、持久、无法从 UI 恢复：insertSessionBefore()（拖拽换组）同样走 mutate 修剪，缓存未命中时拖拽也救不回来；
• 外置盘工作区是被支持的用法（Windows 上盘符/挂载时序本就易变）。凡是「DSH 在盘离线时启动过、盘回来后又动过该工作区」的用户都会中招。

当前补救方法（可供文档/回复引用）

手工编辑 ~\.dsh\storages\workspace.json，把 sessionId 补回对应工作区的 sessionIds，然后带着盘重启 DSH。

证据（本例时间线）

• 受影响会话的 session header cwd 与工作区记录 path 字符串完全一致（排除用户配置问题）；
• 该工作区记录的 updatedAt 恰好等于新会话创建+attach 的时刻，与「修剪写盘」的时间线吻合；
• 同一外置盘的另一工作区（期间无记录写入）成员完好——旁证「写入时修剪」是唯一触发点。

[argszero]

Your trace is exact — including the part that matters most for the fix, that the display filter and the write-side prune are the same predicate over the same cache. A fix for the error class you hit has since landed upstream, so the first question is whether you are on a build that has it.

The prune you identified has been closed for ENOENT. Commit 7d14714601 — "fix(workspace): retain session membership for missing directories" (2026-10-10) — is the first commit that contains the retention, and the first tag containing it is dsh-v0.2.1-alpha.3. Your environment is 0.2.0-rc.2, which predates it.

What master does now, in the same file you read from the asar:

• packages/workspace/workspace/src/index.ts:807-830 — indexHeader(). The catch covers both calls in the try (the realpath and the stat), and when the cwd is fully qualified and the failure carries code === 'ENOENT', the id is added to a second set before being recorded as invalid (:824-827).
• packages/workspace/workspace/src/index.ts:179 and :185 — missingSessionPaths, and the predicate both halves now share: candidateMatches: (id, path) => this.sessionPaths.get(id) === path || this.missingSessionPaths.has(id).
• packages/workspace/workspace/src/entity.ts:102-104 — the sessionIds projection uses that predicate.
• packages/workspace/workspace/src/entity.ts:206-212 — the mutate prune uses the same predicate, so a session whose cwd could not be resolved is no longer dropped when some other write touches the record.

So the two defects you separated — "pruned on write" and "filtered out of the group" — are now one predicate, and a missing directory is exempt from both. The new tests pin the negative side as well: it.each(['EACCES', 'ELOOP', 'ENOTDIR'])('does not preserve candidates after a %s path failure'). Retention is deliberately narrow.

That narrowness is where your case could still be living. Retention keys on the error code, not on "the path did not resolve at index time". A removable or otherwise not-ready volume does not always report ENOENT — a device that is present but not ready, or a BitLocker-locked NTFS volume, can surface as a different failure — and cwd-not-a-directory (:817-819) is deliberately a different verdict from cwd-missing.

The discriminator is already in your logs. On a build with the fix, run the same sequence and watch for the warn — index.ts:844-859:

workspace '<id>' filtered session '<id>' from membership: cwd '<cwd>' does not resolve

If that line appears on >= dsh-v0.2.1-alpha.3, the exemption did not engage for your failure, and the useful upstream change is small and in your report's spirit: keep the membership whenever the cwd could not be resolved at index time, whatever the code. As it stands the log cannot even tell you which it was, because the reason string records the cwd and the fact but not the errno — so the retention decision is unauditable from the log alone. Adding the code to that message is a one-line change that would let the next reporter answer this question themselves instead of reconstructing it from the packaged asar.

Two of your observations are also worth recording as still-valid detail on master:

• bootstrap() still runs only when !state.initialized (:208-214), so a restart genuinely cannot restore what a prune already committed — that was the right diagnosis. With retention in place it stops mattering, because there is nothing left to restore: membership was never lost.
• header.cwd resolving to a file (:817-819) remains an invalid-cwd verdict, not a missing-directory one. That is intended and separate from your report.

For records that were already pruned, before the fix, there is an existing tool: @argszero/cordis-plugin-workspace-membership-doctor@0.1.0 (repo) — a census that reports which members are filtered out and why, plus the repair — which is the half you are currently doing by hand-editing ~/.dsh/storages/workspace.json. It exists for exactly the state your S1 ended up in, and it is not a substitute for the fix above.

If you can re-run the sequence on a current build, the two things worth reporting back are: whether the filtered-session warn appears at all (i.e. whether your failure is ENOENT or something else), and — if it does — the exact errno behind it. That determines whether this is a second retention hole or a stale-build symptom.