[Bug] Conversation fails to load: "conversation Context N:turn-tailM received an update before its start Match" (surface replacement copy ordering)

[geeTomm]

Environment

• dsh web 0.1.0-rc.7 (Windows 11; also reproduced with the same code on WSL)
• Happens when opening an existing session in the chat view

Error

conversation Context 9:turn-tail8 received an update before its start Match

9:turn-tail8 is the turn-tail business context for turn 8 (kind="turn-tail", id 8).

Root cause

ConversationNodeAssembler in @deepseek-ai/dsh-client-runtime throws in three places
(acceptMatch, applyPendingMatches, replayContext) when a turn-tail update match
arrives before its start match.

Real session logs can contain surface replacement copies (surfaceOp: {op:'replace', start, end})
whose ordering does not preserve turn boundaries: a replacement copy of an update
(assistant/message, turn N) can be emitted before the replacement copy of that turn's
turn/start. In our case: assistant/message (turn 8) at seq 149006, then turn/start
(turn 8) at seq 149009 — both inside the same replacement range. Replaying the engine over
all stored sessions reproduced the crash in 3 of 31 sessions (turn-tail 2 / 8 / 13).

Minimal reproduction

Two sanitized events are enough (see repro-events.json): feed them in seq order to
ConversationNodeAssembler.replaceWindow() with the turn-tail Definition registered
(the Definition is copied verbatim from dsh-client-ui-conversation).

[
  {
    "seq": 101,
    "type": "assistant/message",
    "data": { "turn": 8, "step": 0, "message": { "content": [] } },
    "surfaceOp": { "op": "replace", "start": 1, "end": 99 },
    "sourceEventSeqs": [1, 98, 99]
  },
  {
    "seq": 102,
    "type": "turn/start",
    "data": { "turn": 8 }
  }
]

Run the included repro.mjs against a checkout of dsh-client-runtime:

node repro.mjs path/to/dsh-client-runtime/lib/client.js

• Unpatched runtime: ✅ BUG REPRODUCED: conversation Context 9:turn-tail8 received an update before its start Match
• Patched runtime (workaround.patch applied): ✅ OK: no crash

Impact

Any session whose surface replacement range splits a turn can fail to load in the chat view.
This is data-driven (old/compacted sessions), not caused by any plugin.

Suggested fix

Either:

1. Make the engine tolerate out-of-order start: when a start match arrives after earlier
   matches, move it to matches[0] instead of throwing (same in applyPendingMatches /
   replayContext); or
2. Ensure replacement copies are emitted in turn-boundary order (turn/start before updates
   of the same turn).

Local workaround

workaround.patch implements option 1 against dsh-client-runtime/lib/client.js
(three guard points; validated by replaying all 31 sessions: 0 failures, no behavior change
for well-ordered sessions).

---

Note: real session logs are intentionally NOT attached because they contain private
conversation content. The synthetic events above reproduce the bug exactly.
repro-events.json

[argszero]

Verified against rc.8 (141eb6f) — the bug is still present in-tree (not just rc.7), and your root-cause analysis is the right shape. This is a new member of the session-corruption family, with a clean minimal repro. My additions:

1. rc.8 status: still open, same three throw sites

packages/client/runtime/src/client/sessions/conversation-assembler.ts:

• acceptMatch → :425 throw new Error('conversation Context … received an update before its start Match')
• applyPendingMatches → :502 (guards context.matches[0] !== context.start)
• replayContext → :530

No reorder/tolerance logic added between rc.7 and rc.8. So the fix is still pending in-tree, and your workaround.patch (option 1: move the start to matches[0] at all three points) is the live mitigation.

2. The mechanism is a genuine corruption-family member (data-driven, not plugin-caused)

I traced the producer side to confirm your "replacement copies" claim: compaction-basic emits exactly one replace — user/message with surfaceOp: {op:'replace', start, end} at packages/compaction/compaction-basic/src/region.ts:462-464 (the session.append('user/message', checkpointMessage, {surfaceOp: {op:'replace', start, end}, sourceEventSeqs: [startEvent.seq, summaryEvent.seq, ...shadowedSeqs]})). The turn-boundary disorder doesn't come from the append order — it comes from the replay/derivation side: the replacement copies of the shadowed events (assistant/message of turn 8 at seq 149006 vs its turn/start at 149009) are re-emitted in seq order, and when a replacement range splits a turn, the update lands before the turn's start. The engine then refuses the whole session load.

This joins the family of "load-side strictness turns data-driven session shapes into unreadable sessions": #2900/#2661 (balanced-but-dangling tool calls), #2998 (frame-shape throws), #3198 (end-seed seq gap). Like those, the strictness is deliberate (an out-of-order start could indicate corruption) — but here the producer is in-tree compaction itself, so the invariant "replacement copies preserve turn-boundary order" is one the harness cannot guarantee for old/compacted sessions. That changes the calculus: the load side must tolerate it.

3. Your option 1 vs option 2 — and the right call

• Option 1 (reorder at load) is correct as the durable fix, for a specific reason: the source of truth is the session log's seq order, and the surface engine replays copies. A replacement copy of assistant/message before its turn/start is not evidence of corruption — it's the natural emission order when a replacement range splits a turn. The engine's "start must come first" invariant was written for live appends (which are turn-ordered) and is being applied to replay (which is seq-ordered). Your matches[0] move restores the intended invariant without inventing data.
• Option 2 (fix the producer to emit turn-boundary order) can't be the primary fix: it would only help new compactions; the 3/31 existing sessions (and any older compacted session) would still fail to load. It's a good follow-up hygiene (emitting turn/start copies in order reduces future occurrences) but the load-side tolerance is what unblocks existing data.

One implementation note for option 1: when you move the late start to matches[0], make sure the update matches that arrived before it keep their relative order (they do in your patch — the move is a rotation, not a re-sort). Also consider a one-time session-invalidity marker instead of a silent reorder for the case where the start never arrives at all (that would be corruption) — distinguish "late start" (tolerate, reorder) from "missing start" (still refuse).

4. Family + PR shape

This is the 13th report / 11th mechanism in the session-corruption family (12 reports / 10 mechanisms as of #3198; your #3450 adds the replay-ordering mechanism). The PR-ready blueprint: the 3-guard reorder (option 1) + a "late vs missing start" discriminator + a regression test using your two-event repro + a producer-side hygiene note for compaction-basic's replace emission. Your workaround.patch is already validated against 31 sessions — that's the regression corpus.

Nice find — the two-event minimal repro is exactly what makes this actionable, and the "replacement copies are seq-ordered, not turn-ordered" framing is the key insight that separates it from the earlier corruption members.

[denial123789]

I turned the rc.7 reproduction plus the still-present rc.8 (141eb6f) throw sites into an operator-focused recovery runbook: https://sandbaseai.github.io/deepseek-harness-handbook/conversation-update-before-start.html

The key operational boundary is to preserve the untouched Session before changing the reader: this signature is a client conversation-projection refusal and does not by itself prove corrupt persistence bytes. The guide therefore routes export/copy, fresh-Session isolation, safe continuation, and archive before any patched-build experiment. It also carries a 12-gate repair matrix across acceptMatch, applyPendingMatches, and replayContext, including relative update order, duplicate starts, missing starts, location indexes, dependencies, and live/window/replay convergence. No real Session content is used; the incident bundle retains only the ordering and replacement metadata needed for the two-event reproduction.