[Bug] Blank Web sidebar after downgrading: localStorage key dsh.workspace.view.v5 stays the same across incompatible state shapes

[ttkttka]

Summary

Downgrading from 0.1.6-alpha.1 to 0.1.5-rc.2 leaves the Web sidebar completely blank — no workspace rows, no session rows — while the workspace chip above the composer still shows a label. Session files, workspace.json and session_projcache are all intact, the Host prints nothing, no request fails, and a hard reload does not help. The only evidence is a browser-console exception.

Environment

• DSH 0.1.5-rc.2, downgraded from 0.1.6-alpha.1 in the same browser profile (same origin)
• dsh web --port 13080 (the default 3080 sits inside a Windows reserved port range on this machine)
• Windows, Node v24.17.0, Chromium-based browser

Steps to reproduce

1. Run dsh web on 0.1.6-alpha.1, open the GUI and let it mount (this writes the persisted view store into localStorage).
2. Downgrade to 0.1.5-rc.2, restart dsh web, reload the page (a hard reload is not enough).
3. Look at the sidebar and at the browser console.

Actual

The sidebar renders nothing. Console:

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)
    ...
    at client.js:2017:1

Expected

The sidebar lists the workspaces and their sessions.

Root cause

packages/client/ui-workspace/src/client/stores.ts defines a persisted store under the key dsh.workspace.view.v5, and the two release lines disagree about its state shape while keeping the same key.

dsh-v0.1.6-alpha.1 — the field does not exist, and retainAccountKeys removes it:

type WorkspaceViewState = {
  groupBy; orderBy; groupExpansion
  sessionOrderByAccount: Record<string, string[]>
}
...
retainAccountKeys: (d, workspaceKeys) => {
  ...
  delete (d as WorkspaceViewState & { sessionUpdatedAtByAccount?: unknown }).sessionUpdatedAtByAccount
}

dsh-v0.1.5-rc.2 — the field is required and read unguarded:

type WorkspaceViewState = {
  ...
  sessionUpdatedAtByAccount: Record<string, Record<string, number>>
}
...
retainAccountKeys: (d, workspaceKeys) => {
  ...
  d.sessionUpdatedAtByAccount = Object.fromEntries(
    Object.entries(d.sessionUpdatedAtByAccount).filter(([key]) => retained.has(key)),
  )
}

Sources: alpha.1 · rc.2

A browser that has run the alpha therefore persists a dsh.workspace.view.v5 value without sessionUpdatedAtByAccount. On rc.2 the rehydrated draft has that key undefined, so the first retainAccountKeys call throws; the exception reaches the sidebar.workspaces slot's error boundary, which replaces the whole left pane with nothing.

Two aggravating factors:

1. A hard reload does not help, because the value lives in localStorage (per origin). Together with (2) this makes the failure look like permanent loss of all session history.
2. Nothing surfaces it: no Host log line, no failed request, no UI message.

Workaround (verified)

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

Removing only this key restores the sidebar immediately. The auth cookie and every server-side artifact are untouched.

Suggested fixes

1. Guard the reads: Object.entries(d.sessionUpdatedAtByAccount ?? {}) (the other two lines in retainAccountKeys have the same shape).
2. Give incompatible shapes their own persist key, or add version + migrate handling so a client can normalise a value written by another release line. Note the alpha already deletes the field, i.e. the shape change is deliberate — only the key was not separated.
3. Surface a slot failure in the UI instead of rendering an empty pane.

Related

• A failed Session creation is silent: the Web client shows an empty panel while only the browser console explains why #6699 — same reporting gap (silent failure, reason only in the browser console), different cause.
• Web UI does not show existing sessions even though session files and workspace index are intact #6735 — sessions not displayed although session files and the workspace index are intact.

[Ksaredo]

same bug via the upgrade path — see #7314