A corrupt session silently disappears from the session list (no error, no repair path)

[AnnidLin]

A corrupt session log disappears from the session list with no error and no way back

App: DeepSeek Harness Desktop 0.2.1-rc.5 (Windows, app.asar of 2026-10-29)
Observed: 2026-11-03

Symptom

One session stopped opening. The GUI showed:

历史加载失败: stored session "session-43ed7817-..." is corrupt:
stored log is corrupt: SessionFormatError:
developer/message does not match an open turn and step

After a restart the session was gone from the list entirely — no error, no toast, no entry, nothing. The directory was still on disk, complete and readable:

C:\Users\soguw\.dsh\sessions\--D-AIprogram--\session-43ed7817-...\session.v4.jsonl.zstd

So from the user's point of view the conversation was silently deleted. It was not.

What actually broke (two independent layers)

Layer 1 — an event was appended before its step was open

A third-party plugin appends a developer/message from the agent/pre-step waterfall. That hook runs before the loop writes step/start:

• dsh-agent-loop/lib/index.js:910 — await this.dispatch.waterfall("agent/pre-step", …)
• dsh-agent-loop/lib/index.js:971 — this.session.append("step/start", …), only after the waterfall returns

So the plugin's message is written while no step is open. The resulting log has that order:

seq 331  turn/start         turn 3
seq 332  agent/inbox/spliced
seq 334  developer/message  turn 3, step 1   <-- no open step here
seq 335  step/start         turn 3, step 1
seq 336  user/message

Relationships.requireStep (dsh-session-format-v3-to-v4/lib/index.js:574) rejects exactly this on load:

if (this.turn === null || this.step === null || data["turn"] !== this.turn || data["step"] !== this.step)
  throw new SessionFormatError(`${event.type} does not match an open turn and step`);

This is deterministic, not a race. Every time that plugin's rule fires, the message lands before step/start.

Layer 2 — the damage is only discovered on the next open

session.append (dsh-session/lib/index.js:1518) snapshots the data and calls validateSessionEventData, which validates shape only. Nothing checks turn/step relationships at write time. The write succeeds, the process keeps running, and the log is already unloadable.

On the next start, listArtifacts discovers the error and simply drops the entry, which is why the list shows nothing instead of a warning. There is no "file is corrupt, try to recover" path in the UI, and recoverable reading mode still throws on a turn/end boundary.

This is reproducible data, not one bad coincidence

Scanning all 164 local session logs, this exact pattern appears 3 times (the only 3 injections that plugin ever made):

when	session	order on disk (before repair)	outcome
2026-11-02 22:15:47	session-f1f7574c-…	developer/message seq 3699 → step/start seq 3700	corrupt
2026-11-02 22:34:14	session-f1f7574c-…	developer/message seq 4183 → step/start seq 4184	corrupt
2026-11-03 17:17:22	session-43ed7817-…	developer/message seq 334 → step/start seq 335	corrupt

The first two were repaired by hand on 2026-11-02 22:56 (a copy of the pre-repair log is still next to the live one as session.v4.jsonl.zstd.bak-repair-2026-11-02T14-56-15-764Z, and it still shows developer/message sitting before step/start). The third was never repaired, so it became invisible.

Two of three were repaired by luck, not by the app. The user only sees the one that was not.

Repair that worked

Swapping the two adjacent events and exchanging their seq values makes the log valid again (deleting a line is not an option — planSurfaceEvent requires contiguous seq). Verified against the app's own validator:

require('…/@deepseek-ai/dsh-session-persistence/lib/index.js')
  .validateStoredEvents(meta, events, location)   // PASS, 711 events

One more trap for anyone repairing by hand: the log must be re-compressed as two Zstandard frames — the header line alone in frame 1, everything else in frame 2. A single-frame re-compression passes validateStoredEvents and is then silently rejected by assertZstdHeaderFrame (dsh-session-persistence-jsonl/lib/index.js:2298):

corrupt Zstandard session log: first frame is not exactly one header line

Suggested fixes, in order of value

1. Validate relationships at append time. session.append should reuse the same Relationships fold the loader uses and throw at the write site. The bad event would then fail inside the culprit plugin, be caught by its own try/catch, and the log would stay loadable. This alone would have prevented all three incidents.
2. Never drop a corrupt entry silently. listArtifacts should surface the session as "damaged" with the exact reason and the log path, and keep it in the list. A user can then copy the file out before it is lost.
3. Ship a repair path. The swap above is mechanical and safe when the only fault is a message/step ordering inversion. Even a CLI dsh session repair <id> would turn "conversation is gone" into "conversation is back".
4. Make recoverable actually recoverable. Right now it still throws on a turn/end boundary, so the mode does not help the case it is named for.

Environment / evidence

• Windows 11, DSH Desktop 0.2.1-rc.5, app.asar 182,766,714 bytes, mtime 2026-10-29.
• Corrupt log before repair: 283,627 bytes / 455 zstd frames / 712 lines.
• Faulty event: developer/message, source.kind = "dsh-lead-router", form: instructions, time 1793697442683 (2026-11-03 17:17:22 UTC+8).
• All 164 local logs otherwise pass validateStoredEvents (0 further failures), so this is not a general storage problem — it is specifically the "message appended before its step" case that nothing guards.

[PedroCostinha]

Hi! I think session discovery should be independent from successfully parsing the complete session history.

If the session metadata can be enumerated but the event log is damaged, the UI should still display an entry identifying the session as unreadable or corrupted.

That entry could offer safe diagnostic actions such as exporting the original raw data, viewing the parsing error, and creating a backup before attempting repair.

I would avoid automatically rewriting or deleting damaged sessions during normal list loading.

A useful regression test would create a session with a valid metadata record and a corrupted event log, then verify that it remains visible and recoverable through the UI.

This would prevent data corruption from becoming an apparently missing-session problem.