session-persistence writes a turn/end event its own validator rejects (turn: 0 vs turn < 1), and one bad session kills search for the whole store

[sqmagellan]

Summary

dsh-session-persistence writes a turn/end event that its own validator rejects on the next read. Because dsh-session-query-sqlite reconciles every stored session and fails closed on any single bad one, one such session disables session search for the entire store, permanently, with no self-heal.

All packages 0.1.1-rc.2, Node v26.6.0, macOS.

The defect

A stored turn/end event, written by the harness itself:

{"type":"turn/end","seq":5,"time":1788034442786,"data":{"turn":0,"reason":{"kind":"completed"}}}

On the next boot this throws:

SessionQueryError: session-search persistence observation failed:
  stored session "session-..." failed validation:
  Error: session "session-..." contains malformed pre-react-loop turn/end at seq 5
    at malformed (dsh-session-persistence/lib/index.js:585)
    at migrateLegacyTurnEndEvent (dsh-session-persistence/lib/index.js:588)
    at adoptStoredEvents (dsh-session-persistence/lib/index.js:748)
    at PersistenceCoordinator.prepareCore (dsh-session-persistence/lib/index.js:993)

dsh-session-persistence/lib/index.js:588:

if (!Number.isSafeInteger(data["turn"]) || data["turn"] < 1 || !hasOnlyKeys(data, ["turn", "reason"]) || reason === void 0 || typeof reason["kind"] !== "string") return malformed();

Evaluating that predicate against the event above, data["turn"] < 1 is the sole failing clause — every other condition passes. The writer emits a 0-indexed turn; migrateLegacyTurnEndEvent requires >= 1.

So a current-format event with turn: 0 is first misidentified as a legacy pre-react-loop shape, then fails legacy validation. It looks like one of:

• the writer should emit turn >= 1, or
• the legacy guard should not claim a turn: 0 event at all, or
• the bound should be < 0.

Reproduce

With a profile composing dsh-base (which declares session-query-sqlite) plus dsh-session-persistence-jsonl, session-query-sqlite configured openAt: first-search:

1. Boot the profile, create a session, let a turn complete, and run a session search. Passes, and leaves a session containing the event above.
2. Boot again and search. Fails with the error above.

A run that only creates a session without completing a turn is idempotent and keeps passing, which is what isolates the turn/end writer as the source.

Why this is worse than a validation bug

dsh-session-query-sqlite's reconcile walks the whole store, so the failure is not scoped to the offending session — search dies for all sessions. There is no quarantine, no skip-and-continue, and no warning; the only recovery I found was manually moving the session directory out of ~/.dsh/sessions/. This is the second time it has happened on this install.

Two suggestions, independent of the off-by-one:

• Reconcile should degrade per-session, not per-store: skip an unreadable session, surface it as a diagnostic, keep the rest searchable.
• A validator rejecting data this harness itself wrote is worth an assertion in the round-trip tests — write the event, read it back, in the same test.

Happy to supply the full stored session or test more configurations if useful.

[argszero]

Verified every claim against the current tree (cd5ef81 / 0.1.2-alpha.1). Confirmed, with two corrections and one addition.

Confirmed 1 — the validator and the routing. migrateLegacyTurnEndEvent (session-persistence/src/coordinator.ts:389-400) requires Number.isSafeInteger(turn) && turn >= 1 && hasOnlyKeys(data, ['turn', 'reason']) and a string reason.kind, else throws "malformed pre-react-loop turn/end". adoptStoredEvents (:568) and snapshotStoredEvents (:553) route every stored turn/end through it unconditionally. A current envelope with turn: 0 dies there — exactly as you traced.

Confirmed 2 — per-store fail-closed. session-query-sqlite _reconcile (src/index.ts:395-473) wraps all writes in one BEGIN IMMEDIATE/COMMIT; any session that fails to load/validate rolls back everything and rethrows SessionQueryError("session-search reconciliation failed: …"). No quarantine, no skip-and-continue. Your availability point stands.

Correction 1 — the writer is not 0-based; I cannot find any writer that emits turn: 0. The agent-loop emits 1-based turns in both 0.1.1-rc.2 and alpha.1: const turn = phase.turn + 1 (agent.ts:253 / :260), the phase seeded from findLast(turn/start)?.data.turn ?? 0. The crash-repair closer (session/src/repair.ts:131) inherits the stored open turn and only emits when a turn/start exists. There is no turn: 0 literal anywhere in core/session/session-persistence, and no other turn/end writer in the repo. So "the writer should emit turn >= 1" is a red herring — it already does. The provenance of your stored turn: 0 event is unidentified from source alone; if you can share the full session file (or its creation history — fresh on rc.2, or migrated from an earlier build?), that would close it.

Correction 2 — "the bound should be < 0" is the wrong fix. It would accept turn: 0 as a valid current envelope, inconsistent with the 1-based turn/start contract the trace invariant enforces (freshTrace starts nextTurn: 1, session/src/invariant.ts:201), and it leaves the misleading "pre-react-loop" label on genuinely malformed events.

The actual defect — a discriminator gap. The three legacy migrations form a family, and turn/end is the only one without a legacy discriminator:

• migrateLegacyTurnStartEvent (:378) only validates when Object.hasOwn(data, 'trigger') — a legacy-only key; current turn/start passes untouched.
• migrateLegacyMessageEvent (:462-463) documents the rule — "Current-looking malformed events remain untouched so validation rejects them instead of disguising corruption as legacy data" — and guards on current-looking keys.
• migrateLegacyTurnEndEvent (:389-400) has no equivalent guard: it validates every turn/end envelope as if legacy, so a current event that merely fails the envelope (turn: 0, or a corrupt event) is thrown as "malformed pre-react-loop" even though its legacy-ness was never established.

So your middle option — "the legacy guard should not claim a turn: 0 event at all" — is the correct fix, and the concrete shape follows the siblings: claim the event only when its reason shape is one the migration actually upgrades ('disposed', 'aborted' with a legacy reason, 'error' with step + failure/message/code, i.e. the branches at :410-445), and let everything else fall through to the current-format validator with an accurate message. The turn >= 1 clause can then be dropped from the discriminator entirely.

Addition — the live write path never validates turn boundaries. The turn-trace invariant plugin (session/src/invariant.ts) is only imported by examples/agent-spine-demo; dsh-base's own invariant companion (bundle/base/src/invariant.ts) is a documented no-op. So in shipped profiles a bad event is durably written with no live error and only surfaces at next-boot adoption — exactly why your session carried the event silently, and why your round-trip assertion suggestion is the right regression shape (I confirmed there is no turn: 0 coverage in session-persistence tests today).

Net: the fix belongs in the legacy migration's discriminator, not the writer, not the bound; the per-session reconcile degrade is a sound orthogonal availability improvement. Happy to help dig into the writer mystery if you share the stored session.

[liyangbing]

A safe recovery sequence is to stop global search from being the first casualty: preserve the failing Session path and validator output, move only the confirmed-corrupt artifact to a quarantined copy, and verify that healthy Sessions remain searchable before changing the launcher or profile.

The write-side contract should reject turn/end with an invalid turn identity before it reaches the durable store; recovery should never silently rewrite history. Keep one disposable reproduction and record the event sequence, file identity, and restart result. I documented the evidence table and rollback boundaries here: https://sandbaseai.github.io/deepseek-harness-handbook/session-history-corruption-triage.html

Verified against the upstream alpha.1 discussion/source evidence on 2026-08-30. This is an independent community runbook, not an official DeepSeek AI statement.