刚刚安装了

[leenkcool]

体验挺好的。

[ZMLloveMLN]

可以

[leenkcool]

下方的企业微信群不是官方的。 不知道是哪个企业的。 特此说明。

1

[GoN-Kvs]

dsh 预览版（0.1.0-rc.5）在以下场景会把会话日志写坏：
宿主进程被强杀（崩溃/残留）后，dsh web 服务进程残留运行；随后新实例恢复并继续写入同一会话。
恢复的写入方从内存旧 seq 状态续写（比磁盘尾部 seq 回退若干条），与残留服务已落盘的记录形成重复段，
导致 corrupt session log: seq gap in committed region，会话历史永久无法加载（不满足自动修复条件）。

实测损坏结构（解压 zstd 后）：

seq 79439  tool/result          ┐
seq 79440  step/end             │ 第一段：turn 4（interrupted）收尾 + end-seed，完整 0..79442
seq 79441  turn/end interrupted │
seq 79442  session/end-seed     ┘
seq 79439  tool/result   ← 回退重复，新内容（另一段 tool 结果），时间戳 +14s
seq 79440  step/end
...
seq 144010 turn/end     ← 后段内部连续，从 79439 写到 144010

修复方法（已本地验证）：删除重复段开头 4 行，前后段 seq 无缝衔接，事件零丢失。

---

Title: Session log corrupted after crash-restart: seq rewinds and rewrites a duplicate segment, history becomes unloadable

Environment

• DeepSeek Harness 0.1.0-rc.5 (@deepseek-ai/dsh-root), running dsh web
• Windows 11, Node v22.20.0
• Session persisted as session.jsonl.zstd (JSONL, zstd frames via node:zlib)

Symptom

Loading a session's history fails with:

history unavailable for session "session-...": Error: corrupt session log: seq gap in committed region at line 3840 (expected 79443, got 79439)（internal）

The session is then permanently unloadable: the seq gap sits inside the committed region (before the final turn/end), so the automatic repair path (torn-tail truncation / open-turn synthetic closers) never triggers — scanLog throws instead.

Root cause (verified by decompressing the artifact)

The log contains a duplicated segment. Structure at the boundary:

line 3837  tool/result       seq 79439   ┐
line 3838  step/end          seq 79440   │ first run: turn 4 finished (interrupted) + seed sealed
line 3839  turn/end          seq 79441   │            clean 0..79442
line 3840  session/end-seed  seq 79442   ┘
line 3841  tool/result       seq 79439   ← SECOND run rewrites from 79439 (different payload!)
line 3842  step/end          seq 79440
...        (continues internally contiguous up to)
line 7557  turn/end          seq 144010

Timestamps: first run ends 14:59:55 (session/end-seed), duplicate segment starts 15:00:09 — 14 seconds later. The second run's tool/result at seq 79439 has different content, so it is not a replay; it is a new write that started from a stale in-memory seq (79439) instead of the on-disk tail (79443).

Two sessions were corrupted this way (one 144k events, one tiny seed session). All other sessions were clean.

Reproduction steps (suspected path)

1. Start dsh web; open/use a session (some turns committed).
2. Force-kill the host/shell process (crash), leaving the dsh web backend (node) running — the backend keeps the session's in-memory state and may still append.
3. Start a new instance / reconnect to the same workspace, resume the same session and continue chatting.
4. The resuming writer appends from a stale seq (rewrites the last few events as a duplicate segment).
5. Restart everything; opening the session history now fails with seq gap in committed region.

Also seen: a duplicate agent-preset/selected appended after session/end-seed with a reverted seq — i.e. writes happening after the seed was already sealed.

Expected behavior

• On load/recovery, the on-disk committed region is authoritative: any writer that resumes a session must re-align its seq cursor to the disk tail (last committed turn/end / end-seed boundary) before appending, never continue from in-memory state.
• Ideally, detect concurrent writers on the same session artifact (stale backend process still alive) and refuse or serialize instead of appending from a diverged seq.

Suggested fix areas

• packages/session/session-persistence-jsonl/src/format.ts — SessionLogScanner.consumeEventLine currently detects the corruption but cannot repair mid-committed-region gaps; consider a recovery mode that drops the diverged suffix starting at the first reverted seq (it is self-consistent from there) instead of failing the whole log.
• Session resume path — reseed the append cursor from disk state (committedBytes / last seq) rather than the in-memory cursor.
• Optional: write-side guard that rejects an append whose first seq does not match the current file tail (fail loud before corrupting).

Notes

• Data was fully recoverable manually: deleting the 4 duplicate rows makes seq contiguous again (0..79442 + 79443..144010), zero events lost. Re-compressed with the same node:zlib zstd frame format.
• This likely affects the dsh-desktop shell too (it spawns/restarts the dsh web backend and has a stale-instance detection/restart flow).

[leenkcool]

兄弟，可以呀。

[buptrolex-netizen]

加入群讨论

[leenkcool]

1

[shinjiyu]

正经找插件 + 抽象区 MEME + 微信讨论群：
#2397

目录：https://dshoneys.github.io/awesome-dshoneys/
抽象区：https://dshoneys.github.io/awesome-dshoneys/meme.html

码大约到 2026-08-23。不是官方。整活默认不要开。

[Tazio7]

Same signature confirmed on another deployment (macOS 26.6.2 arm64, dsh 0.1.1-rc.2, launchd-managed daemons): three session logs corrupted after restarts, identical pattern — the retiring process drains a session/end-seed, the replacement process's first agent/inbox/spliced reuses the seed's seq.

Two additions to the evidence in this thread:

1. Timing-independent: collisions occurred 42s and ~1h after the drained end-seed — so this is a deterministic resume-base accounting issue, not a flush/torn-write race.
2. Seq repair alone is insufficient: after surgically restoring seq contiguity (validated with decodeStorageRecord), resume still failed with cannot publish session "…": persisted state already owns this identity until the conversation was rotated to a fresh session identity. The whole post-seed segment written by the stale-base process behaves as poisoned.

Full reproduction, environment, and a containment design (frame-preserving repair + 60s heartbeat auto-check) posted in #2817: #2817 (comment)