[Bug] 摘要失败后立刻丢弃旧上下文，不会重试压缩直到成功 / Failed compaction drops history instead of retrying summarization

[YahooYuan666]

What happened? / 发生了什么

Automatic context compaction often does not produce a real summary. On failure it immediately writes a retained_tail fallback checkpoint (~112 tokens of recovery prose) and omits older messages from the next model request. The UI still shows this as a successful row: 上下文已压缩 · 第 1 次 摘要 ≈ 112 tokens.

This is distinct from #224. #224 / PR #249 made the fallback recoverable (non-empty last-user tail, strip the fallback marker so a later compaction can try a real summary). On this compaction attempt, summarization is still one-shot: fail → drop history. There is no retry-until-a-real-summary-exists loop.

长会话自动压缩经常压不出真正摘要。失败后立刻写入 retained_tail 回退检查点（约 112 tokens 的恢复说明），并从下一次模型请求里丢掉旧消息。UI 仍显示成成功：上下文已压缩 · 第 1 次 摘要 ≈ 112 tokens。

这和 #224 不是同一件事。#224 / PR #249 让回退可恢复（非空的最后一条用户消息、剥掉 fallback 标记以便下一次压缩再试真摘要）。这一次压缩仍然是一锤子：失败 → 丢历史。没有「重试直到压出真摘要」的环。

Steps to reproduce / 复现步骤

1. Open PI-Desktop 0.14.8 on Windows, Agent mode, a long coding session.

2. Let the context grow until automatic compaction fires (hard limit). Typical tokensBefore here: ~190k–330k, one case ~885k.

3. Watch the transcript row 上下文已压缩 · 第 N 次 摘要 ≈ 112 tokens.

4. Ask the model about decisions, file paths, or unfinished work from before that row.

5. Windows 上打开 PI-Desktop 0.14.8，Agent 模式，跑长会话。

6. 等到自动压缩触发（硬上限）。本机 tokensBefore 常见约 19–33 万，有一次约 88 万。

7. 看到 上下文已压缩 · 第 N 次 摘要 ≈ 112 tokens。

8. 再问压缩点之前的决策、路径、未完成工作。

Expected behavior / 预期行为

Compaction is a model summarization pass over the conversation.

• Transient failure (timeout, 5xx, dropped stream): retry the same summary request until it completes.
• Input too large for one request: do not skip the model. Shrink or chunk (map-reduce / truncate tool output) and retry until a real structured summary exists.
• Only after retries are exhausted should a safety net keep a bounded recent original tail (on the order of keep-recent, not one user message).
• The UI must not present a failure stub as 摘要 ≈ 112 tokens. Say that summary generation failed.

压缩的本质就是调模型把上下文走一遍总结。

• 瞬时失败（超时、5xx、断流）：重试同一次摘要请求直到完成。
• 一次塞不下：不要跳过模型。缩小或分段（map-reduce / 截断工具输出）再压，直到产出结构化真摘要。
• 只有重试耗尽，才允许保有界近期原文（keep-recent 量级，而不是一条用户消息）。
• UI 不要把失败占位显示成 摘要 ≈ 112 tokens，应标明摘要生成失败。

Actual behavior / 实际行为

Inspected local session JSONL + installed resources/agent-runtime/sidecar.js on 0.14.8:

1. Codex-shaped preparation folds all history into messagesToSummarize and keeps at most the latest user message (active_turn) or none (completed_turn). keepRecentTokens no longer decides what survives.
2. compactionSummaryWouldExceedBudget — if history + previous summary ≥ window − output budget − 2048 — never calls the model and fails immediately.
3. generateCompaction / compact() may retry transient stream drops internally, but buildCheckpoint does not re-run summarization with a smaller payload.
4. recoverCompactionFailure writes failureCode: CONTEXT_COMPACTION_FAILED, fallback: retained_tail, summary ≈:

No previous context checkpoint is available.

[automatic context recovery: older context was omitted after summary generation failed]
…
Older messages before this checkpoint are omitted from the next model request.

That stub is ~451 chars ≈ 112 tokens — exact match for the UI.

5. retainedTailForContext then keeps only the latest user message, or [] on completed_turn.

Local counts on this machine (sanitized): 6 / 10 compaction entries were this stub. The 4 successes produced real 4–6k-character summaries (~1k–1.5k tokens). So when summarization runs, it works; the failure path is what wipes memory.

本机 0.14.8 的 session JSONL 和安装包 sidecar.js：

1. Codex 形状把全部历史折进 messagesToSummarize，最多留最后一条用户消息（active_turn），结束回合则一条不留。keepRecentTokens 不再决定谁活下来。
2. compactionSummaryWouldExceedBudget：历史 + 上次摘要 ≥ 窗口 − 输出预算 − 2048 时，不调模型，直接失败。
3. compact() 内部可能重试断流，但 buildCheckpoint 不会缩小输入再跑一轮摘要。
4. recoverCompactionFailure 写入上述 ~112 tokens 占位。
5. retainedTailForContext 只留最后一条用户消息，或 completed_turn 时为空。

本机 10 次压缩里 6 次是这种占位；4 次成功摘要有 4–6k 字。模型能压时压得出，失败路径才会把记忆清掉。

App version / 应用版本

0.14.8

Operating system / 操作系统

Windows

Extra environment / 额外环境信息

• Windows x64
• protocol 11
• host / app 0.14.8
• NSIS install
• v0.15.0 changelog does not mention a retry-until-summary loop; this report is from 0.14.8 which already includes PR fix(agent-runtime): keep context recoverable after a failed compaction #249.

Logs / 日志

Compaction checkpoint details (typical failure):

{
  "failureCode": "CONTEXT_COMPACTION_FAILED",
  "fallback": "retained_tail",
  "generation": 1,
  "retainedTailMode": "active_turn"
}

tokensBefore examples: 198218, 205803, 329313, 885339.

No full transcript attached (privacy). Happy to add redacted sidecar traces if useful.

Related

• [Bug] 上下文压缩失败后切换模型无法恢复会话历史 / Model switch loses context after failed compaction #224 / fix(agent-runtime): keep context recoverable after a failed compaction #249 — fallback must not restore empty context; does not retry summarization on the failing attempt
• [Feature] 设置页增加上下文压缩阈值（keepRecent / reserve） / Expose compaction keepRecentTokens and reserveTokens in Settings #203 — settings for keepRecent / reserve; Codex shaping currently ignores keepRecent for survival
• [Bug] After context compaction, the agent can resume an old task instead of the current task #22, [Bug] 使用opencode供应商手动压缩报错 #398 — other compaction / provider-header issues

Suggested fix (for maintainers)

In packages/agent-runtime compaction path:

1. On transient summary failure: retry the summary call with backoff (cap N).
2. On compactionSummaryWouldExceedBudget: chunk or truncate tool results and still call the model; merge partial summaries.
3. Last resort only: persist a bounded recent original tail (8k–20k), not a 112-token notice.
4. UI: if failureCode === CONTEXT_COMPACTION_FAILED, show “摘要生成失败”, not “摘要 ≈ 112 tokens”.

[ZxlDragonDoctor]

I'd like to take this. Proposed scope (first slice):

1. On transient summary failure, retry the same summarization call with backoff (capped N) before writing a fallback checkpoint.
2. When compactionSummaryWouldExceedBudget would skip the model, still attempt a reduced payload (truncate tool outputs) instead of failing closed.
3. Only after retries are exhausted, persist a bounded recent original tail — not a 112-token notice presented as a successful summary.
4. UI: if failureCode === CONTEXT_COMPACTION_FAILED, show summary-generation failed rather than 摘要 ≈ 112 tokens.

Non-goals for this PR: map-reduce multi-pass summarization; changing Codex-shaped keepRecent survival rules (tracked in #203).

Tests: unit coverage for retry-then-succeed, retry-exhausted fallback, and UI failure label.

[vastsa]

已核对 0.15.0 main 上的代码，问题属实，且比「没有重试」更多一层。根因有三处，修复在 #563（ADR 0282 / D445）：

1. 摘要请求完全没有重试。 generateCompaction 调 pi-agent-core 的 compact() 时 retry 参数传的是 undefined，pi-ai 的 retryAssistantCall 在没有 policy 时 maxAttempts = 0，第一次失败的响应原样返回。主对话的 provider 重试（D186）挂在 streamFn 包装上，但摘要走的是 Models.completeSimple，根本不经过那层。所以一次断流、一次 503 就直接进 retained_tail。

2. 预算预检量错了东西。 compactionSummaryWouldExceedBudget 对原始消息逐条 estimateTokens 求和，但 pi-agent-core 真正发出去的是 serializeConversation 拼成的一段文本，每条 tool result 在序列化时已经截到 2 000 字符。工具输出多的会话，原始估算比实际 prompt 大好几倍，守卫就在不调模型的情况下直接判失败。你贴的 tokensBefore 200k–885k 对 200k 窗口，正是这种形状：原始上下文确实溢出，但序列化后的摘要请求本来放得下。

3. UI 分不清回退和摘要。 ContextCompactionMark 只区分 fresh_window，回退检查点的 details.fallback = "retained_tail" 没有传到 mark 上，所以 451 字符的恢复说明按 4 字符/token 算成 ≈112 tokens，显示成「摘要 ≈112 tokens」。

修复内容：

• compact() 传入有界 RetryPolicy（3 次重试，2s/4s/8s，Stop 可取消）。由 pi-ai 的分类器判定瞬时错误（overload/429/5xx/断流/超时/连接重置），配额、鉴权、参数错误仍然第一次就返回，不会白等。
• 预检按 pi 实际序列化的 prompt 估算；仍然超窗口时，恰好再试一次缩减输入（tool result 截为 500 字符前缀并标注、去掉 thinking 块），不删任何消息，checkpoint 覆盖的范围和原来一致。缩减后仍放不下才走 ADR 0049 的回退。
• mark 新增 fallback?: "retained_tail"，转录行显示「摘要生成失败 · 已保留近期上下文」，不再显示 摘要 ≈N tokens。历史上已经写入的回退检查点在重新打开会话时也会显示成失败标签。

没做的：map-reduce 分段摘要（ADR 0282 记为 deferred，缩减后仍放不下的输入还是走回退）；keepRecent 存活规则（#203）；回退尾部大小不变。

---

Verified against main (0.15.0): the report is accurate, with one extra cause. Fixed in #563 (ADR 0282 / D445).

1. No retry on the summary request. compact() was called with retry: undefined; pi-ai's retryAssistantCall then makes zero retries. The main turn's D186 retry wraps streamFn, which the completeSimple summary path never reaches.
2. The preflight guard measured raw messages, not the prompt. pi-agent-core serializes the conversation to text and caps each tool result at 2 000 chars; the guard summed estimateTokens over raw messages instead, so tool-heavy sessions were routed to the fallback without a model call even when the real prompt would fit. Your 200k–885k tokensBefore on a 200k window is exactly this case.
3. The UI could not tell a fallback from a summary. details.fallback never reached ContextCompactionMark, so the 451-char notice rendered as summary ≈112 tokens.

Fix: bounded pi-ai RetryPolicy (3 retries, 2s/4s/8s, abort-aware, transient-only); guard sizes the serialized prompt; one reduced pass (tool results cut to a 500-char prefix, thinking dropped, no message removed) before the fallback; mark.fallback + a "summary generation failed · recent context retained" row label. Deferred: map-reduce summarization for inputs that overflow even reduced.