[Bug] 从 0.1.7-rc.2 回退到 0.1.5-rc.2 后左侧会话列表全空：两版共用 persist key dsh.workspace.view.v5，0.1.7 删掉了 sessionUpdatedAtByAccount / Empty session list after downgrading 0.1.7-rc.2 → 0.1.5-rc.2 (shared persist key, field deleted)

[liualiez-os]

Summary

在同一个 DSH Web 服务（http://127.0.0.1:3080）上先后跑过 0.1.7-rc.2 和 0.1.5-rc.2，回到 0.1.5 后：左侧会话栏还在，但会话列表是空的（没有任何会话条目），F12 Console 抛出 TypeError: Cannot convert undefined or null to object，被错误边界捕获为 slot entry crashed in 'sidebar.workspaces'。

根因是两个版本共用同一个持久化键 dsh.workspace.view.v5，却在这个键下使用了不同的字段集：0.1.7 在 retainAccountKeys 里 delete d.sessionUpdatedAtByAccount，而 0.1.5 的 retainAccountKeys 无条件对 d.sessionUpdatedAtByAccount 调 Object.entries()。回退后 hydration 用水合数据整体替换了 init 默认值 → 该字段为 undefined → 抛错 → 整个列表槽位渲染为空。会话数据本身完好无损，用户看到的是「列表空了」，很容易误判成会话丢失。

English TL;DR — 0.1.7-rc.2 and 0.1.5-rc.2 share the persisted store key dsh.workspace.view.v5 but not its schema: 0.1.7 deletes sessionUpdatedAtByAccount, while 0.1.5 unconditionally calls Object.entries() on it. Downgrading in the same browser origin hydrates the 0.1.7 payload over 0.1.5's defaults, the store action throws inside produce, and the error boundary blanks the whole sidebar.workspaces slot. No session data is lost. Reproducible without any third-party launcher: run dsh web 0.1.7, then 0.1.5, on the same port.

Environment

OS	Windows 10 Enterprise 22H2, build 19045.6456 (zh-CN)
Node	v24.18.0 (C:\Program Files\nodejs\node.exe)
Browser	Chrome 154.0.8037.57, page http://127.0.0.1:3080
Affected	DSH 0.1.5-rc.2
Trigger source	DSH 0.1.7-rc.2
Shared origin	both served on 127.0.0.1:3080 → one browser localStorage bucket
Third-party client plugins	none involved in the diagnosis; the crashing package is the official @deepseek-ai/dsh-client-ui-workspace

本机的具体形态是「用启动器装了两个整合包，各带一份 DSH 本体」：

pack	dshVersion	homePath（DSH_HOME，互相隔离）
pack-test（官方默认整合包 0.1.5-rc.2.1）	0.1.5-rc.2	…\dsh-packs\pack-test
pack-test-2（官方默认整合包 0.1.7-rc.2.1）	0.1.7-rc.2	…\dsh-packs\pack-test-2

两者的 webPort 都是 3080。本 issue 不依赖这个启动器——下面给出去掉启动器的最小复现路径。

Reproduction

A. 最小复现（不依赖任何启动器／整合包）

1. 用 0.1.7-rc.2 在 3080 端口启动 Web（dsh web），打开页面并正常操作一次（切换工作区、点开一个会话），让 store 持久化写入 localStorage['dsh.workspace.view.v5']。
2. 停掉它，换 0.1.5-rc.2，同一个端口再启动 Web（同一浏览器、同一 profile）。
3. 打开页面：左侧会话栏出现，但列表为空，Console 报下面的错。

B. 我实际遇到的路径（两个整合包，服务端环境互相隔离）

1. 0.1.5 的 pack 先跑（写入含 sessionUpdatedAtByAccount 的 v5）。
2. 切到 0.1.7 的 pack 跑一次：不崩（0.1.7 的 retainAccountKeys 只 delete、不读那个字段），但它把 archivedFilter: "default" 写进同一个键。
3. 切回 0.1.5 的 pack：崩，列表空。

一行自证（在 0.1.5 的页面 Console）

location.origin                                  // http://127.0.0.1:3080
JSON.parse(localStorage.getItem('dsh.workspace.view.v5'))
// 触发状态下：含 archivedFilter:"default"，不含 sessionUpdatedAtByAccount
localStorage.removeItem('dsh.workspace.view.v5')  // 清掉后刷新即恢复（会重置分组/排序偏好）

如果把 0.1.7 与 0.1.5 两个页面的 location.origin 和上面那份 JSON 并排截一张图，就是现场证据。

Expected / Actual

• Expected：回退到 0.1.5 后能正常显示已有会话列表（storages/sessions 里的数据是完整的）。
• Actual：列表全空；Console 有报错，UI 无任何提示，用户无法区分「会话没了」和「渲染崩了」。

Console output (0.1.5-rc.2, verbatim)

index-BKQ_L1z6.js:56 TypeError: Cannot convert undefined or null to object
    at Object.entries (<anonymous>)
    at retainAccountKeys (client.js:218:1)
    at index-BKQ_L1z6.js:56:69359
    at index-BKQ_L1z6.js:56:68694
    at produce (index-BKQ_L1z6.js:56:66201)
    at Object.update (index-BKQ_L1z6.js:56:68674)
    at a.<computed> [as retainAccountKeys] (index-BKQ_L1z6.js:56:69348)
    at client.js:2017:1
o0 @ index-BKQ_L1z6.js:56

client.js:526 slot entry crashed in 'sidebar.workspaces': TypeError: Cannot convert undefined or null to object
    at Object.entries (<anonymous>)
    at retainAccountKeys (client.js:218:1)
componentDidCatch @ client.js:526

Root cause

packages/client/ui-workspace/src/client/（发布产物 lib/client.js）。

0.1.5-rc.2

196  function createWorkspaceViewStore() {
197    return defineStore({
198      init: () => ({
199        groupBy: "workspace",
200        orderBy: "updated",
201        groupExpansion: {},
202        sessionOrderByAccount: {},
203        sessionUpdatedAtByAccount: {}      // ← 0.1.5 需要这个字段
204      }),
205      persist: "dsh.workspace.view.v5",
...
214      retainAccountKeys: (d, workspaceKeys) => {
215        const retained = new Set(workspaceKeys);
216        d.groupExpansion = Object.fromEntries(Object.entries(d.groupExpansion).filter(([k]) => retained.has(k)));
217        d.sessionOrderByAccount = Object.fromEntries(Object.entries(d.sessionOrderByAccount).filter(([k]) => retained.has(k)));
218        d.sessionUpdatedAtByAccount = Object.fromEntries(Object.entries(d.sessionUpdatedAtByAccount).filter(([k]) => retained.has(k)));  // ← 抛错行
219      },

调用点在 workspacePhase 变 ready 后的 effect 里，所以每次挂载都会走一遍：

2015  useEffect(() => {
2016    if (workspacePhase !== "ready") return;
2017    actions.retainAccountKeys(["", FLAT_SESSION_ORDER_KEY, ...workspaces.map((w) => w.workspaceId)]);
2021  }, [actions.retainAccountKeys, workspacePhase, workspaces]);

0.1.7-rc.2（同一个包里）

656  function createWorkspaceViewStore() {
657    return defineStore({
658      init: () => ({
659        groupBy: "workspace",
660        orderBy: "updated",
661        groupExpansion: {},
662        sessionOrderByAccount: {},
663        archivedFilter: "default"          // ← 取代 sessionUpdatedAtByAccount
664      }),
665      persist: "dsh.workspace.view.v5",     // ← 键没升到 v6，与 0.1.5 撞车
...
678      retainAccountKeys: (d, workspaceKeys) => {
679        const retained = new Set(workspaceKeys);
680        d.groupExpansion = Object.fromEntries(Object.entries(d.groupExpansion).filter(([k]) => retained.has(k)));
681        d.sessionOrderByAccount = Object.fromEntries(Object.entries(d.sessionOrderByAccount).filter(([k]) => retained.has(k)));
682        delete d.sessionUpdatedAtByAccount;  // ← 0.1.7 主动删掉该字段
683      },

两个辅助细节

• 为什么偏偏崩在第 218 行：栈里报的是第三个字段（sessionUpdatedAtByAccount），而 216／217 两行正常通过 → 说明 hydration 是整体替换（不是与 init 默认值浅合并），并且持久化载荷里恰好只缺这一个字段，与 0.1.7 的 payload 形状完全吻合。
• 方向性：0.1.5 → 0.1.7 不会崩（新代码只 delete、不读该字段）；只有 0.1.7 → 0.1.5 会崩。也就是说这个键被写成新 schema 之后，旧版本就再也起不来了。

隔离边界（与第三方启动器／多整合包的关系）

本机用的是一个社区启动器（DSH Launcher 0.1.3 portable），它把 DSH 本体和插件路径都搬到了 per-pack 目录下，并且声称各整合包环境隔离。实测的隔离边界是：

层	位置	是否被整合包隔离
DSH_HOME（sessions / storages / profiles / credentials / settings.yaml）	…\dsh-packs\pack-test vs …\dsh-packs\pack-test-2	✅ 各自独立
插件与依赖（含 profile junction profiles\web → profiles\pack-test）	各自 pack 的 homePath 内	✅ 各自独立
DSH 本体（runtime）	dsh-runtime\versions\0.1.5-rc.2 / 0.1.7-rc.2，每次启动指向对应版本	✅ 版本级独立
浏览器 origin 存储（localStorage / cookie / HTTP cache）	http://127.0.0.1:3080 + 同一浏览器 profile	❌ 完全共享，不隔离

dsh.workspace.view.v5 存在 localStorage 里，作用域是 协议+主机+端口（origin），与 DSH_HOME、插件路径、runtime 目录毫无关系。而启动器的 settings.json 里只有一个全局 "webPort": 3080，packs.json 里没有任何 per-pack 端口字段 —— 所以两个 pack 用的是同一个 origin、同一份存储。所谓「环境隔离」只覆盖磁盘侧服务端状态，反而制造了错觉：每个 pack 看起来都是干净独立的环境，用户不会怀疑浏览器里那份共享状态。

这解释了 bug 为什么是单向的，也说明复现只需要两个条件：

1. 同一个 origin（同端口）。若两个环境配了不同端口，则不会互相中招——新 origin 的桶是空的，0.1.5 会走自己的 init 默认值，一切正常。
2. 同一个浏览器 profile。若一个跑在系统浏览器、另一个跑在宿主内置窗口且 user-data 目录不同，也可能是两个独立桶。

影响面交叉验证（已做全量 sweep）

枚举两个版本 .pnpm 下所有 @deepseek-ai/dsh-client-*\lib\client.js，提取 persist: 字符串与 delete d.X：

版本	包	persist	delete
0.1.5-rc.2	dsh-client-ui-workspace	dsh.workspace.view.v5	—
0.1.7-rc.2	dsh-client-ui-workspace	dsh.workspace.view.v5	delete d.sessionUpdatedAtByAccount
0.1.7-rc.2	dsh-client-ui-sidebar-browser	dsh.sidebar-browser.v1（新包新键）	—

即：两版唯一共用的持久化键就是 dsh.workspace.view.v5；0.1.7 全部客户端包里唯一的字段删除就是 delete d.sessionUpdatedAtByAccount。该冲突在客户端包里只有这一处，不是范围性问题（其余包的 persist: 没有字符串键）。

Suggested fix

1. 结构性（推荐）：schema 变更时把 persist 键升到 dsh.workspace.view.v6 并附带一次性迁移，把旧 v5 载荷归一化成新形状；不要用 delete 表达跨版本字段下线。
2. 防御性（建议同时做）：hydration 归一化（init 默认值 ← 载荷的浅合并），或按现有风格给 Object.entries(x ?? {}) 兜底——这样任何来源的旧／新载荷都不会把 render 打崩。
3. 健壮性：slot entry 抛错时整块列表直接变空白、UI 无提示，建议至少把错误暴露到 UI（或降级渲染），让用户能区分「数据没了」和「渲染崩了」。

Workaround（用户侧，二选一）

• 清键后刷新：localStorage.removeItem('dsh.workspace.view.v5')（只重置分组/排序偏好，不影响会话数据）。
• 或给 0.1.5 的那几行加 null 兜底（本地用一个 4 处 ?? EMPTY_RECORD / if (d.x === void 0) d.x = {} 的守卫补丁验证通过：列表恢复，且会把缺字段补 {} 回写持久化数据，自愈）；需要的话我可以把它整理成幂等、锚点不匹配即拒绝的补丁脚本再附链接。

Additional context

• 触发场景是「同一个端口先后跑两个版本／两个整合包」；即使没有启动器，只要同一 origin 上先后跑过 0.1.7 与 0.1.5 就会中招。
• 给启动器／多环境使用者的经验性缓解：为不同 DSH_HOME 分配不同端口（origin 隔离），不要共用一个 webPort。
• 共用 origin 的影响不止这一个键：localStorage、cookie、HTTP 缓存都是两套环境共享的，值得一并提醒。