DSH cross-workspace Session recovery

DSH Cross-Workspace Session Moves: Registry Recovery

Author
DeepSeekAgent.io Editorial Team
Published
Updated

A DeepSeek Harness v0.2.1-rc.3 community case documents a complete Session-migration failure chain. A large Session was moved from Workspace A to Workspace B through the UI and the process was interrupted. Two divergent copies with the same Session ID remained. The target copy lived under B's storage path while its header cwd still pointed to A. On the next launch, Workspace Registry could not establish a consistent stored identity, leaving Registry-dependent services pending.

This case matters because it traces an invisible-session failure back to its producer. Earlier recovery work focused on how readers should isolate a malformed record. The new reproduction shows how an interrupted cross-workspace move can create that record.

What a move has to change

A menu action that moves a Session represents several persistence operations:

  1. copy or rewrite the Session event file and compressed artifacts;
  2. update the header cwd, ID, and format metadata;
  3. replace source and target workspace ownership;
  4. publish the final state to Workspace Registry and dependent services.

If those writes become visible independently, the system exposes intermediate states. In the reported reproduction, the target held 3,035 event lines while the source held 3,045. Copying had stopped before the tail completed. The target path already existed, but the header and Registry still represented the old ownership. The result was a shorter copy in the new location and a more complete copy in the old location.

Why one divergent copy can block eight services

DSH validates a Session's stored identity. The path says Workspace B, the header cwd says Workspace A, and the same Session ID appears in two places. Once assertStoredIdentity rejects that combination, Workspace Registry cannot finish initialization.

The report lists eight affected service areas, including the Session controller, Schedule, Workspace controller, UI deliverables, Task board, Git graph, and Archive. These are not eight independent defects. They share a Registry readiness dependency that never settles. The UI can remain in a loading state while downstream services stay pending.

That symptom can look like a broken workspace or deleted history. A more useful diagnostic path starts with why Registry did not become ready, then checks duplicate IDs, path/header disagreement, and copies with different event lengths.

Recover the event superset first

Recovery should preserve the most complete Session history while restoring one authoritative identity:

  1. fully quit DSH and copy the complete data directory and both workspaces with timestamps intact;
  2. locate every copy by Session ID and compare headers, event counts, tail records, and attachment references read-only;
  3. identify the event superset instead of choosing only by modification time or directory;
  4. validate that the superset parses completely on the backup;
  5. quarantine redundant copies rather than deleting them;
  6. align the final storage path, header cwd, and Registry ownership;
  7. restart and verify recent messages, attachments, compaction records, task data, and Session continuation.

If each copy has events missing from the other, file size alone is insufficient. Confirm whether they share a common event prefix before attempting any merge. Preserve both originals when the sequences have diverged.

The move needs a transaction boundary

A resilient cross-workspace move can use a prepare, validate, switch, and clean sequence:

  • Prepare: write a temporary target copy and durable migration marker.
  • Validate: compare event counts, hashes, header fields, and attachments.
  • Switch: change the single Registry owner through a recoverable commit.
  • Clean: retire the source only after the target opens correctly.

After a restart, the migration marker provides enough state to continue, roll back, or offer recovery. A partial target must not become an ordinary Session, and one conflicted artifact must not block the complete Registry. Reader-side per-artifact isolation remains important so unaffected workspaces continue to load.

This article complements the invisible Session diagnosis and recovery guide: that guide examines list tolerance, while this one explains how a path-divergent copy can be produced. Users who frequently move long Sessions should back up first and avoid terminating Desktop before the move finishes.

References

FAQ

Should the target-directory copy always win when a Session appears twice?

No. Compare event sequences, headers, attachments, and tail records. Protect the copy that is complete and passes parsing validation.

Does a loading Workspace mean every Session is damaged?

No. One identity-conflicted record can block Registry initialization while the remaining Sessions are intact.

Can I repair the incident by changing only the header cwd?

First reconcile the Registry, storage path, and duplicate ID. Changing only cwd can leave the second copy and preserve the identity conflict.