Windows 0.2.1-rc.5: workspaceController unavailable; workspace list stuck loading

[123456wcom]

Hi, I’m experiencing the same workspaceController error as in discussion #10908.

Environment:

• Windows
• DeepSeek Harness 0.2.1-rc.5

Error when adding a workspace:
workspace create failed: gateway/service-unavailable: typert gateway: workspace/create: active Service "workspaceController" is unavailable

Current symptoms:

• The app opens, but the workspace list is empty and remains stuck at “Loading workspaces…”.
• In the original %USERPROFILE%.dsh\storages folder, there was no active workspace.json; several .bak and .broken files were present.
• I copied workspace.json.broken-20261102 to workspace.json as a test. The app still shows the same loading state.
• Session data files still exist under %USERPROFILE%.dsh\sessions. For example, the bili-whale session file is 2,911,171 bytes.
• I have made two copies of the entire .dsh directory. I have not modified the session data files.

Could you advise how to safely collect the host stderr/startup logs on Windows and verify whether a stored workspace record violates the workspace schema? I want to diagnose this without overwriting session data. I also need guidance on restoring the uncategorized session list safely.

I can provide redacted configuration excerpts and logs if needed.

[123456wcom]

已尝试从 PowerShell 启动，但 stdout/stderr 仅有更新检查和本地 Web 地址；原有的 crash-...host.log 报告在启动时 corrupt session entry，路径涉及 bili-whale.bak-...

[PerryLink]

The stuck list is a failed activation, not a slow load.

WorkspaceController injects ['remoteAccess', 'typert', 'workspaceRegistry'] (packages/api/workspace-controller/src/index.ts:55-56). If workspaceRegistry throws while activating, this service never exists, so every workspace/* call answers gateway/service-unavailable — the exact text you got.

Where the throw comes from: the registry opens the domain at packages/workspace/workspace/src/index.ts:200, and each stored record is parsed at packages/storage/storage-domain/src/index.ts:126. parseRecord (:198-209) wraps a schema failure as invalid-record and names the table and key. The workspace domain does not opt into backup-and-skip (packages/workspace/workspace/src/spec.ts:76-84), so the record is not moved aside — the open fails (storage-domain/src/index.ts:131).

The one line worth grepping in the host output:

domain 'workspace': stored record '<key>' in table 'workspaces' does not match its schema

(message body at storage-domain/src/index.ts:205). If that line is absent, the failing parse is more likely the domain's global state, whose schema is spec.ts:57-65; same code path, different message.

What the file must contain. Each workspace record is path/title strings, sessionIds an array of strings, createdAt/updatedAt strings (spec.ts:24-30). The global state is initialized boolean plus workspaceIds array, with archivedSessionIds and pinnedSessionIds defaulting to empty arrays (:57-65). A sessionIds: null or a missing title is enough to fail.

Resuming without touching sessions. Sessions live under sessions/ and are not part of this domain, so nothing here deletes them. The registry has a bootstrap path for a missing state: initialized: false plus workspaceIds: [] means "rebuild accounting from session headers" (spec.ts:46-47, :81). So the safe sequence is: keep your two .dsh copies, move the workspace storage file aside, start once, and the uncategorized list repopulates from session headers — at the cost of workspace grouping, order, and titles.

Collecting host stderr. The desktop keeps its logs under app.getPath('logs') (apps/desktop/src/main.ts:143), which is %APPDATA%\@deepseek-ai\dsh-desktop\logs on Windows; ctx.logger.error output only lands there when it accompanies a report, so crash-*-host.log may not contain this. The reliable way to see it is to boot the same profile from a shell with the CLI (dsh --profile desktop) and read stderr, or to run the Host entry directly the way #11759 does.

If you paste the storage error line (or say it is absent), I can tell you which of the two schemas is failing.

Read-only source inspection at master ce7073d5; I did not run your storage files.