Bug: web sidebar lists no workspaces and no sessions after upgrade (0.1.5-rc.2)

[Xkipper]

Bug: web sidebar lists no workspaces and no sessions after upgrade — persisted store shape changed without bumping the persist key (0.1.5-rc.2)

Environment

DSH	0.1.5-rc.2 (global npm install, dsh web)
OS	Windows (also reproduced by reading the shipped client bundles)
Node	v24.18.0
Browser	<fill in: e.g. Chrome/Edge xyz>
Origin	http://127.0.0.1:3080
Trigger	Upgrade via npm install -g @deepseek-ai/dsh over an earlier 0.1.5-rc build

Symptom

The left sidebar shows no workspaces and no sessions at all — the list is completely empty. Everything else in the GUI works normally: chat, attachments, model selection, settings, and the session transcript. A hard reload (Ctrl+Shift+R) does not help, and the state survives browser restarts.

Console evidence

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

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)

Root cause

1. @deepseek-ai/dsh-client-ui-workspace persists its view store in localStorage under the literal key dsh.workspace.view.v5:

   init: () => ({
     groupBy: "workspace",
     orderBy: "updated",
     groupExpansion: {},
     sessionOrderByAccount: {},
     sessionUpdatedAtByAccount: {}
   }),
   persist: "dsh.workspace.view.v5",

2. The client store helper hydrates by replacing the state with the stored JSON — it does not merge init() defaults, so a field absent from the stored record stays undefined:

   // dsh-client-store helper bundled in the shell (index-*.js), function Tc(t, r)
   const i = localStorage.getItem(r);
   if (i !== null) t.setState(M6(JSON.parse(i)), true);

3. A record persisted by an earlier 0.1.5-rc build uses the same key v5 but predates the sessionUpdatedAtByAccount field. retainAccountKeys then dereferences the missing field:

   retainAccountKeys: (d, workspaceKeys) => {
     const retained = new Set(workspaceKeys);
     d.groupExpansion = Object.fromEntries(Object.entries(d.groupExpansion).filter(([key]) => retained.has(key)));
     d.sessionOrderByAccount = Object.fromEntries(Object.entries(d.sessionOrderByAccount).filter(([key]) => retained.has(key)));
     d.sessionUpdatedAtByAccount = Object.fromEntries(Object.entries(d.sessionUpdatedAtByAccount).filter(([key]) => retained.has(key))); // ← throws here
   },

4. The call happens in an effect the moment the workspace projection becomes ready (lib/client.js:2015-2021), i.e. exactly when the list is about to render:

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

5. The throw escapes into the sidebar.workspaces slot entry, its error boundary catches it (client.js:526) and renders nothing. Result: a permanently empty sidebar in that browser, on every load, with no visible error and no way to recover from the UI.

Minimal reproduction

1. Open the web GUI and go to DevTools → Application → Local Storage for the GUI origin.

2. Set dsh.workspace.view.v5 to a pre-sessionUpdatedAtByAccount shape:

   {"groupBy":"workspace","orderBy":"updated","groupExpansion":{},"sessionOrderByAccount":{}}

3. Reload. The sidebar lists no workspaces and no sessions, and the console shows the trace above.

4. Run the workaround below: the sidebar returns immediately, with every workspace and session intact.

Workaround

localStorage.removeItem('dsh.workspace.view.v5');
location.reload();

Only browser-local view preferences are lost (which groups were expanded, manual row order). Workspaces and sessions live in $DSH_HOME/storages/workspace.json and the session store, and are untouched.

To keep those preferences, repair the record instead of dropping it:

const k = 'dsh.workspace.view.v5', s = JSON.parse(localStorage.getItem(k) || '{}');
s.groupExpansion ??= {}; s.sessionOrderByAccount ??= {}; s.sessionUpdatedAtByAccount ??= {};
localStorage.setItem(k, JSON.stringify(s)); location.reload();

Note: localStorage is per origin, so a browser that reaches the GUI on a different origin (e.g. localhost vs 127.0.0.1, or a LAN address) holds a separate record and needs the same fix there.

Suggested fixes

1. Guard the dereferences (d.groupExpansion ?? {}, etc.) so an already-poisoned browser recovers on the next reload instead of losing the whole sidebar. This is the fix that unbreaks existing users.
2. Bump the persist key (or add a version field with a migration) whenever the persisted shape changes — the shape grew while the key stayed dsh.workspace.view.v5.
3. Merge on hydrate ({...init(), ...stored}) in the store helper, so a field added in a later build can never be undefined.
4. Surface slot crashes: today a crashed sidebar.workspaces entry renders as a silently empty sidebar, which reads as "my conversations are gone".

Diagnostic notes

• dsh --profile web --dump-config shows all 53 web client plugins mounted and enabled, including ui-sidebar, ui-workspace and workspace-controller; the profile composition is not at fault.
• session_diagnose reports all 6 stored sessions as ok, and the workspace registry/directories resolve correctly under realpath — the data is intact. This is purely client-side persisted-state handling.
• The reporter's web profile additionally mounts a third-party plugin (dsh-sessions-diagnosis, added with dsh plugin --profile web add .). It is unrelated to the trace, and the crash reproduces from the persisted value alone with no plugin involved.

[PerryLink]

Your reading of the shipped bundle is correct, and the fix has already landed -- you need the
upgrade, not a patch.

What is confirmed at HEAD (ddefc45, 0.1.6-alpha.2):

1. The hydration behaviour is real and still there. packages/client/store/src/index.ts:152-155
   replaces the whole state with the stored JSON and never merges init() defaults:

   const raw = localStorage.getItem(name)
   if (raw !== null) {
   api.setState(devFreeze(JSON.parse(raw) as T), true)
   }

   That is the Tc(t, r) you decompiled. The doc comment above it (:138-145) explains the
   hand-rolled persistence is deliberate -- zustand's middleware spreads state and corrupts
   primitive values -- but the side effect you found is real: a stored record missing a field
   keeps that field undefined forever.

2. retainAccountKeys no longer dereferences the missing field; it deletes it.
   packages/client/ui-workspace/src/client/stores.ts:89:

   delete (d as WorkspaceViewState & { sessionUpdatedAtByAccount?: unknown }).sessionUpdatedAtByAccount

   init() (:66-71) now returns only groupBy, orderBy, groupExpansion and
   sessionOrderByAccount, and the only Object.entries calls in the action (:83-88) read
   fields that init() always supplies. The cast in that line is the tell: the type does not
   know the field because it only ever arrives from persisted state.

3. That line is a migration shim for exactly your scenario, and it is the fix. git log -S lands
   on d19d23c, "fix(workspace): make manual session order browser-local" (2026-09-11); its
   stores.ts diff replaces the per-account recency map with sessionOrderByAccount and adds the
   delete. git tag --contains d19d23cf86 returns dsh-v0.1.6-alpha.1 and dsh-v0.1.6-alpha.2
   only -- not dsh-v0.1.5-rc.2. Your build has the new read without the shim, which is precisely
   why it wedges.

So: on 0.1.5-rc.2 the immediate workaround is to drop the poisoned record --
localStorage.removeItem('dsh.workspace.view.v5') in devtools, then reload; the sidebar rebuilds
from init() because the key is absent. Adding the missing key by hand also works but is more
fragile. Upgrading past that commit is the real answer.

One caveat worth carrying forward, because your root-cause analysis is more durable than the fix
that landed: the persist key is still 'dsh.workspace.view.v5' at HEAD (packages/client/ui-workspace/src/client/stores.ts:72). The
shim works because someone knew the exact stale field name; the next field renamed under the same
key needs another one. Bumping the key, or merging init() defaults on hydrate, removes the
class.

I have not run the 0.1.5-rc.2 build -- the version boundary above comes from the tag graph, and
the source citations from the committed tree.

[archer-ec]

Verified against the published npm artifacts, since the tag-graph inference above left the 0.1.5-rc.2 side unrun. Same conclusion, now from the shipped tarballs rather than the source tree (npm pack both versions, then read lib/client.js):

Package	init()	retainAccountKeys
@deepseek-ai/dsh-client-ui-workspace@0.1.5-rc.2	declares sessionUpdatedAtByAccount: {}	d.sessionUpdatedAtByAccount = Object.fromEntries(Object.entries(d.sessionUpdatedAtByAccount)...) — line 218
@deepseek-ai/dsh-client-ui-workspace@0.1.6-alpha.2	field absent	ends with delete d.sessionUpdatedAtByAccount — line 280

Both keep persist: "dsh.workspace.view.v5", so the shim is the fix rather than a key bump, and the published alpha does carry it. Line 218 of the rc.2 artifact is also exactly where the browser stack trace points, which closes the loop on the "new read without the shim" reading.

Two details worth adding to the repro:

1. The failure is per-browser, which makes it read like a browser-compat bug. Firefox 156 on macOS 26.6.2 showed the empty sidebar; Chrome 153 on the same host, against the same dsh web process and the same session store, was completely fine — the poisoned record existed only in Firefox's localStorage for that origin. Nothing about the sessions themselves differed, so "it works in another browser" is not evidence that the stale record is gone; it is evidence that browser never wrote one.

2. localStorage.removeItem('dsh.workspace.view.v5') + reload is confirmed working on 0.1.5-rc.2: the sidebar rebuilds from init(), and since the store rewrites on the next update, the record stops being shapeless. This is a per-browser, per-origin fix — it has to be done wherever a stale record exists.

Gecko's phrasing of the same TypeError, for anyone searching the message text:

TypeError: can't convert undefined to object
    retainAccountKeys client.js:218
slot entry crashed in 'sidebar.workspaces': TypeError: can't convert undefined to object
    retainAccountKeys client.js:218

Agreed on the durable point in the parent comment: the key is still v5 at HEAD, so this shim covers exactly one field name. Merging init() defaults on hydrate, or bumping the key, is what removes the class.

[PerryLink]

Thanks - the tarball check is the piece I could not do. I had run the tag graph but not the 0.1.5-rc.2 build, so "new read without the shim" was inference on my side; your lib/client.js line numbers plus the browser stack trace make it measurement. The per-browser detail is the part I would have got wrong if I had tried to reason about it: nothing about the sessions differed, so "fine in Chrome" says the record was never written there, not that it was repaired.

Where it stands at 0.1.7-alpha.1 (c36a83ff6b), since upgrading is the recommendation:

• The shim is still there: packages/client/ui-workspace/src/client/stores.ts:108 deletes the obsolete ledger, and the key is still dsh.workspace.view.v5 (:91).
• Hydration is still a whole-value replace with no default merge - packages/client/store/src/index.ts:152-155, unchanged.

But I have to correct the durable point I made above, because the shipped answer is better than what I proposed. I wrote that the next field added under the same key would need another shim. That is too strong. archivedFilter has since been added under the same v5 key, with no bump and no shim - and it is safe, because the class is now handled by a convention with both halves written down:

stores.ts:29   /** Archived-row visibility; omitted in pre-filter v5 snapshots and read as 'default'. */
stores.ts:30   archivedFilter?: ArchivedFilter
:89            archivedFilter: 'default',            // init()

The persisted-state type marks the late field optional and documents why, and the read site owns the default: WorkspaceBrowser.tsx:848 is useStore(s => s.archivedFilter ?? 'default'). A stale record therefore keeps the field undefined and still renders correctly, instead of wedging.

Both halves are pinned, which is why I trust it:

• packages/client/ui-workspace/tests/workspace-browser.client.spec.tsx:401 mounts on a v5 record with no archivedFilter, and :412 asserts the store value is undefined - i.e. the default is deliberately at the read site, not in the store.
• :385-397 pins the shim itself: the obsolete ledger is present in the stored record and gone from the rewritten one.

So the shim is only needed for a field that cannot be read defensively - the old ledger was consumed by Object.entries(d.sessionUpdatedAtByAccount), and Object.entries(undefined) throws, which is exactly your can't convert undefined to object. A field read behind ?? never needs one. That narrows the residual to "a non-optional persisted field read without a default", which is a smaller and more checkable thing than what I said above.

Boundary: all of the above is read from the committed tree at c36a83ff6b; I have not run 0.1.7-alpha.1 in a browser, and I never reproduced the Firefox case.

[Ksaredo]

Confirmed on 0.1.5-rc.2 (Windows, dsh web, Chrome at 127.0.0.1:3080): the sidebar flickers for ~1 s, then the whole sidebar.workspaces slot dies — no workspaces, no sessions; only manually opened conversations stay reachable. Same class from the other direction in #6823.

The d19d23c shim explains it exactly: rc.x builds iterate sessionUpdatedAtByAccount without the delete, so a pre-d19d23c snapshot wedges them. One extra observation from my side that may be useful for the class discussion:

• On rc.3 (code-identical to rc.2), the bug stopped reproducing after a guarded local run (?? {} in retainAccountKeys): subscribe re-serialized a complete snapshot into localStorage after the first successful cycle, so the polluted record self-heals. Fresh profiles / cleared site data / downgrades still trip it.

Given the convention now covers late optional fields with read-site defaults (archivedFilter), one residual question: groupExpansion and sessionOrderByAccount are still required in the persisted type and read via Object.entries(...) without a default — a snapshot missing either would wedge the same way. Do they get read-site defaults too, or is that the accepted residual?