Repository navigation
Session log becomes unreadable: compaction summary shadows the protected system head (0.2.1-rc.2, still on rc.5) #11580
环境
项 | 值
-- | --
DSH | 桌面版 0.2.1-rc.2（nightly 通道，app.asar 2026-10-17）
关键包 | @deepseek-ai/dsh-compaction-basic@0.2.1-rc.2、@deepseek-ai/dsh-session-persistence-jsonl@0.2.1-rc.2、dsh-session-format-v2-to-v3 / v3-to-v4@0.2.1-rc.2
OS | Windows 11 x64
模型 | deepseek-flash（1M 上下文）
自定义插件 | 有若干第三方插件，但 compaction / persistence 均为官方原版，未打补丁
日志格式 | session.v4.jsonl.zstd（zstd 多帧）
修复后又继续对话的会话，逐段统计都是 100%（「新增压缩数 = 新增违规数」）： 代码块 决定性证据： |
Replies: 1 comment 2 replies
|
Your reader quote is right, but seq 8 doesn't end up in the span through the positional
Your repair confirms it: it only edits the summary and the file validates, so no checkpoint ever replaced seq 8, and those compactions never applied. Check the zstd -dc session.v4.jsonl.zstd | jq -c 'select(.type == "compaction/summary" or .type == "compaction/end") | {seq, type, start: .data.shadowedRange.start, error: .data.error}'So the question is what requests that range. I ran this against the published 0.2.1-rc.2 and rc.5 packages (Node 24.18, macOS). With a system head at node 0, automatic compaction started at node 1, also after a mid-session |
|
确认你的分析，并按你的判据在本机验证了——同时找到了请求那个范围的调用方。 你给的判据是「查坏摘要之后的 8 条违规、8 条 error，一一对应。 调用方找到了：第三方插件
const result = await compaction.compactRegion(range.start, range.end, agent, signal);范围来自它自己的选段函数 const shadowedSeqs = surface.slice(0, keepFromPosition) // 从 surface[0] 起，未跳过 system head
.map(asSeqNumber).filter((seq) => seq !== undefined);
return { start: shadowedSeqs[0], end: ..., shadowedSeqs, ... };它复刻了 你那条判断我在 rc.2 的已装产物上逐点核过，全部成立（不是复述，是读本机
所以链路是完整的四段：官方选段会跳过 → 插件选段不会 → 前置校验不管 → 只有替换时拦。中间那两段不存在任何一层能挡住这次调用。 对照实验：关掉该插件的滚动压缩后，自动压缩开始成功同一台机器、同一个 profile，只改「插件开着 → 关掉」这一个变量。下面「含头」指该次
合计：自动 1076 次、成功 3 次（0.3%）；手动 11 次、全部成功（11/11）。 关键对照： 一个需要收回的说法我上一版写过「即使
两种失败形态里，只有一种会把日志搞坏（但要更正一句）失败 ≠ 摘要非法。 形态 A（
形态 B（
但「含不含系统头」本身不是成败判据——这一点要单独说清，否则会被读成「含头就坏、不含头就好」：
所以「含不含头」只影响摘要是否合法（日志会不会坏），不影响替换会不会被拒（压缩有没有落地）。我们的判据因此从「 供你判断的两点
（环境：Windows 11、DSH 桌面 0.2.1-rc.2、Node 24.21.0；行号对应 |
|
That's a clean control, thanks for running it. Same profile, same Both of your open points are issue material rather than something I can settle from here:
If the answer got you there, could you mark it as the answer? Then the next person who hits （简单说：触发者是插件自己的 |
That's a clean control, thanks for running it. Same profile, same
start, only the plugin'scontextCompactionEnabledturned off, and the auto compaction lands. So the failing calls come fromdsh-graphmemory's owncompactRegionpath, not the core one.Both of your open points are issue material rather than something I can settle from here:
dsh-graphmemoryauthor: it starts atsurface[0]without thefirstIdxskipselectCompactableRangedoes, and your per-session success/failure counts are exactly the evidence they'll need.compactRegionto reje…