Overflow recovery produced no compaction attempt after CONTEXT_WINDOW_EXCEEDED (no compaction/start recorded; session stays dead)

[nicecx]

现象

会话在收到 provider 确认的 CONTEXT_WINDOW_EXCEEDED 后，未记录任何压缩尝试；后续每次唤醒/重试仍以同类报错结束（同一会话累计 8 次 CONTEXT_WINDOW_EXCEEDED），直至 turn/end.reason.kind=error 终止，会话进入"每次唤醒都撞同一面墙"的状态。

环境 / 证据

• dsh 0.1.5-rc.2、deepseek-flash、window 1,048,576、默认输出预留 256,000（与另一条 issue 同环境）
• 会话记录（约 8.8MB、3141 行）统计：
  • CONTEXT_WINDOW_EXCEEDED ×8；maximum context ×8
  • compaction/start = 0；compaction/summary = 0；compacted-summary = 0
• 时间线样例：turn 41 首次报错（requested 1048596 = 792596 messages + 256000 completion）→ 至 turn 44 仍为同类报错后 terminated（另一样本会话序列一致）。

期望 vs 实测

compaction-basic README 描述：agent/request-error 监听器对 provider 确认的 CONTEXT_WINDOW_EXCEEDED 会绕过常规阈值与保留策略、做一次最大平衡头部缩减，并在 surface replacement generation 前进后授权重试。
实测：未观察到任何压缩尝试落地（无 compaction/start），会话直接死亡。

疑问

1. 恢复是否有前置条件（open turn / step boundary / generation advance）导致在"已 closed 的会话"或"重试回合"里无法启动？
2. 恢复失败是否可在会话记录里留下痕迹（当前完全静默，诊断困难）——哪怕一条"恢复尝试失败"的持久化记录？
3. 若压缩请求本身需要全量历史而在超限会话上不可行，是否应提供更轻的兜底（先裁剪/外置再压缩）？

影响

长会话一旦错过压缩窗口即进入死亡循环（每次唤醒都撞同一面墙），只能靠外部重建会话恢复；对长驻 agent 工作流影响大。

[shubham-kr2002]

try switching models it will help

[PerryLink]

在 master（c291e7961）核对：恢复机制存在，但你的"0 次 compaction/start"是四个静默出口之一造成的，且失败都发生在事务开始之前。

机制：agent/request-error 监听器（packages/compaction/compaction-basic/src/index.ts:180-224）在 failure.code === 'CONTEXT_WINDOW_EXCEEDED'（:184）时尝试恢复；成功条件 = replaceGeneration 前进（:219-220），且默认只允许 1 次重试（config.ts:93）。compaction/start 只在事务内部 append（region.ts:210），所以 0 次 start = 每次都在事务前退出。

四个静默出口：

1. selectCompactableRange 返回 null → 直接 return null 不记录（index.ts:289-290；region.ts:117-155）。
2. 恢复抛错 → 只 logger.warn，不写会话记录（index.ts:196-217）。
3. 无开启 turn → compactRegion 抛错（region.ts:197-202），走出口 2。
4. 监听器根本没注册：构造器只在 config.auto 时注册（index.ts:127-131），而 host 树默认禁用 compaction-basic（packages/bundle/web-app/cordis.patch.yml:427-434），替代挂载在 preset 隔离域（packages/preset/agent-presets/presets/standard/agent.cordis.yml:138-156）——如果你的部署树没挂载该 preset 组，就是完全静默（未验证：你的部署树是否挂载，这是第一优先确认项）。

建议：先确认 preset 挂载；再看会话日志里是否出现过 context-overflow compaction failed: ... 的 warn（出口 2 的唯一痕迹）；然后可要求补一个持久化的诊断事件（如 compaction/aborted），把"选不到范围/无 turn/无监听器"落盘而不是吞掉。另外你在 #6671 的附注同根：两个帖子的现象大概率是同一个部署问题。

[nicecx]

感谢 @PerryLink 的逐行核对与缓解建议。补三组现场数据：

1) 预设挂载确认（你标为"第一优先确认项"的那项）：已挂载。我们实测中 host 平面与 preset 隔离域两个 compaction-basic 实例都在（同一次 agent/pre-step 会同时打到两个实例），pluginInventory 中三件套 enabled+active。

2) 在"静默出口"里，还有一个比阈值逻辑更早的位置（两条自动腿+手动腿都会中）：
compactIfNeeded 的第一条语句 meter.measure(session) 即抛
TypeError: this.adapters.get(...)?.adapter.imageRequestPricing is not a function。
触发条件：有插件以普通对象字面量注册 LLM 适配器（非 LlmAdapter 子类，不继承基类默认 imageRequestPricing(){}；我们环境中的实例＝社区插件 dsh-vision-router）。这在 dsh-llm 的调用点（本机 0.1.5-rc.2 为 lib/index.js:1997）只保护了 map 取用、未保护方法存在性——与该方法的文档承诺（"unknown providers degrade to undefined rather than throwing"）相悖。
后果：抛点在 measure() 内 ⇒ 事务开始前即退出（即你说的"恢复抛错"出口形态），自动压力/自动溢出/手动压缩三腿全灭；且在无 exporter 的 logger 上连 warn 也不可见。
复现：任何带此类适配器的环境，在全新会话（我们实测约 13.5K token）上执行手动压缩即可复现原文；我们另用 CDP 在运行进程的 warn 前一帧抓到了该 TypeError 及适配器成员表。会话档 0 次 compaction/* 与之完全一致。

3) 修复后现场（供验证参考）：把阈值调至 0.65（我们改的是 preset 行配置；你提的 modelPolicies 写法已记下）＋适配器侧补齐后，实测压缩生效：compaction/start → summary → end（压力 750,742 → 579,327），压缩后回合正常完成。

建议（供参考）：核心侧按自身文档做降级守卫（typeof adapter?.imageRequestPricing === 'function'，否则 undefined；一行），这样任何第三方适配器形态都不会静默熄火压缩；另 +1 你提的持久化诊断事件——"尝试失败"与"从未尝试"目前从外部无法区分。

需要 CDP 捕获原文/逐步复现，随时可提供。

[gorban]

Complementary case on the same harness version, from the opposite direction — recovery ran, repeatedly, and could not succeed.

session-2496881f-8d36-4ce6-93d9-1954a31930c7 (dsh 0.1.6-alpha.2, openrouter/deepseek/deepseek-v4.1-flash) recorded 79 compaction/start events and 59 failures, every one rejected by the shrink guard in summarizeCompaction:

summary is not smaller than the shadowed content (2237 estimated framed tokens >= 2237)

39 of the 59 are exact equality, and 48 attempts happened inside a single turn. So where your session shows zero attempts, this one shows attempts that are structurally incapable of succeeding: the selected span is the checkpoint the previous compaction wrote (19 of 20 successful compactions selected a one-node span equal to the prior checkpoint). Details: #7212

There is also a second reason recovery can be skipped in this session, which may be relevant to your diagnosis of "no compaction/start recorded": the five final turns returned finish_reason: "length" with exactly one output token on a ~287k-token prompt. pi-ai's length-stop overflow check requires usage.output === 0:

if (contextWindow && message.stopReason === "length" && message.usage.output === 0) { … }

One token and the check misses, so packages/llm/llm-pi-ai/src/stream.ts maps the response to { kind: 'max-tokens' }, agent/request-error never sees CONTEXT_WINDOW_EXCEEDED, and no recovery is attempted at all — the turn just ends and continue reproduces it. Details: #7214

Worth recording in the session log either way, per your question 2: both failure modes are silent. In this session the only trace of the 59 rejections is compaction/end with an error field; the pre-step listener just logs step compaction failed: …; continuing the turn and moves on.

Evidence: https://gist.github.com/gorban/4725c87390cb391047a2f14b56b98d28