fix(runtime): malformed compaction summaries can permanently strand a session

[somewan820]

English

What happened

A tool-heavy Desktop Session can become permanently stranded after automatic history compaction returns a provider-completed but structurally invalid summary.

Observed on main@3a9824a7e with a custom openai-responses-compatible connection and gpt-5.6-sol:

• the selected model had no declared contextWindow, so Runtime used the bounded fallback capacity (32,000 history budget + 16,384 reserve);
• the active Turn accumulated large GitHub issue and pull-request tool results;
• active tool-result pruning ran and reported 74 pruned results / 352,159 estimated tokens saved;
• history compaction then ran eight times in the same Turn;
• all eight model calls completed, but every compaction decision failed open with malformed_summary_missing_section;
• the final Turn outcome was context_budget_exhausted;
• a short follow-up message immediately ran another history_compact call, which completed with finishReason: stop after 113,942 ms (37,498 input tokens, 1,895 output tokens), but the Turn still ended as context_budget_exhausted with detail summarizer_failed.

The summary validator is behaving correctly: an incomplete summary must not replace durable history. The liveness defect is that the same Session has no bounded repair or escape path. Repeating or regenerating can issue the same doomed compaction again, while Desktop presents only the generic "Task run failed" toast.

The Session history remained intact and Runtime Host stayed ready; there was no process exit. GitHub access itself was not the failure.

How to reproduce

1. Configure a custom Responses-compatible relay model without declaring its context window, so the default bounded fallback applies.
2. Start a Desktop Session that accumulates enough text-heavy tool results to exceed that capacity. Fetching several full GitHub issue / PR bodies in one Turn reproduces the observed shape.
3. Make the history summarizer return non-empty text with finishReason: stop that omits one or more required checkpoint sections.
4. Observe that the summary is correctly rejected as malformed_summary_missing_section and no checkpoint is written.
5. Continue until the outgoing request remains over capacity.
6. Observe context_budget_exhausted.
7. Send a short follow-up message or regenerate.
8. Observe another completed history_compact request followed by the same terminal failure, with no actionable recovery guidance.

This should also be covered deterministically with an injected summarizer; it does not require a live provider test.

Expected behavior

• Keep the strict checkpoint-summary validator introduced for fix(runtime): history compaction accepts truncated/unstructured LLM summaries without validation #3029. A malformed summary must never replace folded history.
• Bound repair attempts for a given compaction input/failure fingerprint. Do not repeatedly spend model calls on an identical malformed-summary outcome.
• After the bounded attempt is exhausted, preserve a stable diagnostic reason such as malformed_summary_missing_section through the terminal projection.
• Present actionable recovery: configure the model's real context window, switch model/connection, or start a fresh task/branch.
• A changed model, connection, context-window declaration, or source-history fingerprint may retry; an unchanged failure should not loop blindly.
• Add regression coverage for an over-capacity, tool-heavy history whose summarizer completes normally but omits required sections.

The exact repair mechanism (one stricter retry, structured-output summary, alternate summarizer, or another bounded strategy) can be decided in implementation. Weakening or bypassing summary validation is not an acceptable fix.

Environment

• Maka commit: 3a9824a7e
• Maka version: 0.2.0 development build
• Surface: Desktop + Runtime Host
• OS: macOS 26.6 / Darwin 25.6.0 arm64
• Electron: 43.4.1
• Node.js: 24.18.1
• Provider type: custom openai-responses-compatible
• Model: gpt-5.6-sol
• Runtime Host: remained ready; no local process exit captured

Logs, screenshots, or additional context

First failed Turn diagnostics:

contextWindow: null
failureClass: context_budget_exhausted
compaction decisions:
  failedOpen / context_limit / malformed_summary_missing_section: 8
  unchanged / context_budget_exhausted: 1
latest main input tokens: 43,145
active pruned tool results: 74
active estimated tokens saved: 352,159

Immediate follow-up Turn:

callKind: history_compact
status: completed
finishReason: stop
latency: 113,942 ms
input tokens: 37,498
output tokens: 1,895
terminal detail: summarizer_failed
failureClass: context_budget_exhausted

Related:

• fix(runtime): history compaction accepts truncated/unstructured LLM summaries without validation #3029 added the safety-critical malformed-summary validator. This issue keeps that invariant and addresses the resulting dead-end recovery path.
• fix(runtime): context budget measures stored events, so hydrated image payloads count as zero #3372 documented real malformed_summary_missing_section completions as an out-of-scope compaction defect in a separate image-budget incident.
• feat: user-overridable model facts (context window etc.) — models.json-style override layer #2330 tracks user-overridable model facts. A missing relay context window amplified this incident, but silently assuming an official-provider limit for a custom relay is not the proposed fix here.

Out of scope:

• changing the actual context limit exposed by a custom relay;
• weakening checkpoint validation;
• an unrelated Electron MaxListenersExceededWarning observed earlier in the same app process.

AI assistance disclosure: Codex inspected the local durable Runtime records and source, drafted this report from the reporter-provided diagnostic, and posted it at the reporter's request.

简体中文

发生了什么

当自动历史压缩返回一个 provider 已正常完成、但结构不合法的摘要时，一个工具结果很多的 Desktop Session 会被永久卡住。

在 main@3a9824a7e 上观察到该问题，使用的是自定义 openai-responses-compatible 连接和 gpt-5.6-sol：

• 所选模型没有声明 contextWindow，因此 Runtime 使用了有界回退容量（32,000 history budget + 16,384 reserve）；
• 当前 Turn 累积了大量 GitHub issue 和 pull request 工具结果；
• active tool-result pruning 已运行，并报告裁剪 74 个结果、预计节省 352,159 tokens；
• 随后在同一个 Turn 中运行了八次历史压缩；
• 八次模型调用都正常完成，但每次压缩决策都以 malformed_summary_missing_section 失败开放；
• 最终 Turn 结果为 context_budget_exhausted；
• 紧接着发送一条很短的后续消息后，又立即运行了一次 history_compact。该调用在 113,942 ms 后以 finishReason: stop 正常完成（37,498 input tokens、1,895 output tokens），但该 Turn 仍以 context_budget_exhausted 结束，详情为 summarizer_failed。

摘要校验器的行为是正确的：不完整摘要不能替换持久历史。活性缺陷在于，同一个 Session 没有有界的修复或退出路径。重复发送或重新生成可能再次发起同一个注定失败的压缩，而 Desktop 只显示泛化的“任务运行失败”toast。

Session 历史仍然完整，Runtime Host 也始终保持 ready，没有进程退出。GitHub 访问本身不是失败原因。

如何复现

1. 配置一个没有声明上下文窗口的自定义 Responses-compatible relay 模型，使其采用默认有界回退。
2. 启动一个 Desktop Session，并积累足够多的文本类工具结果，使其超过该容量。一次 Turn 中读取多个完整 GitHub issue / PR 正文可以复现本次观察到的形态。
3. 让历史摘要器返回非空文本和 finishReason: stop，但缺少一个或多个 checkpoint 必需章节。
4. 观察摘要被正确拒绝为 malformed_summary_missing_section，且没有写入 checkpoint。
5. 继续运行，直到实际待发送请求仍然超过容量。
6. 观察 context_budget_exhausted。
7. 发送一条很短的后续消息或执行重新生成。
8. 观察另一次正常完成的 history_compact 请求，以及随后相同的终止失败；界面没有提供可操作的恢复建议。

该问题也应通过注入摘要器进行确定性测试，不需要依赖真实 provider 测试。

预期行为

• 保留 fix(runtime): history compaction accepts truncated/unstructured LLM summaries without validation #3029 引入的严格 checkpoint 摘要校验器。格式错误的摘要绝不能替换被折叠的历史。
• 对同一个压缩输入/失败指纹限制修复尝试次数，不要在完全相同的坏摘要结果上反复消耗模型调用。
• 有界尝试耗尽后，通过终态投影保留稳定的诊断原因，例如 malformed_summary_missing_section。
• 提供可操作的恢复路径：配置模型的真实上下文窗口、切换模型/连接，或者启动新的任务/分支。
• 当模型、连接、上下文窗口声明或源历史指纹发生变化时可以重试；条件没有变化时不应盲目循环。
• 增加回归覆盖：一个超过容量、工具结果很多的历史，其摘要器正常完成但遗漏必需章节。

具体修复机制（一次更严格的重试、结构化输出摘要、备用摘要模型或其他有界策略）可以在实现阶段决定。削弱或绕过摘要校验不是可接受的修复。

环境

• Maka commit：3a9824a7e
• Maka 版本：0.2.0 development build
• 使用面：Desktop + Runtime Host
• OS：macOS 26.6 / Darwin 25.6.0 arm64
• Electron：43.4.1
• Node.js：24.18.1
• Provider 类型：自定义 openai-responses-compatible
• 模型：gpt-5.6-sol
• Runtime Host：始终保持 ready；没有捕获到本地进程退出

日志、截图或其他上下文

第一次失败 Turn 的诊断：

contextWindow: null
failureClass: context_budget_exhausted
compaction decisions:
  failedOpen / context_limit / malformed_summary_missing_section: 8
  unchanged / context_budget_exhausted: 1
latest main input tokens: 43,145
active pruned tool results: 74
active estimated tokens saved: 352,159

紧接着的后续 Turn：

callKind: history_compact
status: completed
finishReason: stop
latency: 113,942 ms
input tokens: 37,498
output tokens: 1,895
terminal detail: summarizer_failed
failureClass: context_budget_exhausted

相关 issue：

• fix(runtime): history compaction accepts truncated/unstructured LLM summaries without validation #3029 增加了安全关键的坏摘要校验器。本 issue 保留该不变量，只处理由此暴露出的无路可走的恢复路径。
• fix(runtime): context budget measures stored events, so hydrated image payloads count as zero #3372 在另一个图片预算事故中，把真实的 malformed_summary_missing_section completion 记录为超出其范围的压缩缺陷。
• feat: user-overridable model facts (context window etc.) — models.json-style override layer #2330 跟踪用户可覆盖的模型事实。缺少 relay context window 放大了本次问题，但本 issue 不提议为自定义 relay 静默假定官方 provider 的限制。

非目标：

• 修改自定义 relay 实际暴露的上下文限制；
• 削弱 checkpoint 校验；
• 处理同一应用进程中更早出现、但与本问题无关的 Electron MaxListenersExceededWarning。

AI 协助披露：Codex 检查了本地持久化的 Runtime 记录和源码，基于报告者提供的诊断起草本报告，并按报告者要求发布。

[testikun]

This was generated by AI during triage.

The reproduction test has been retained locally. At this point, only the Runtime test fixture has changed; no production code has been modified and no commit has been created. The reproduction test and the Runtime build both pass.

The retained test is:

packages/runtime/src/__tests__/mid-turn-capacity-backend.test.ts (around line 990)

What the problem actually is

Maka's history compaction does not delete history. It creates a checkpoint projection:

Canonical RuntimeEvent history
        ↓
summarizer generates a summary
        ↓
summary structure validation
        ↓
valid: write checkpoint
invalid: keep raw history and continue

Keeping the original history when validation fails is correct: a malformed summary must never become a new source of truth.

The problem is that the failure path is currently only fail open; it does not limit subsequent attempts.

First compaction failure

When the request approaches the context limit, Runtime enters compaction. The summarizer can complete normally while returning text that omits the required checkpoint sections.

The validator rejects that result as malformed_summary_missing_section:

packages/runtime/src/history-compaction.ts (findCheckpointSummaryDefect / checkpoint admission)

The resulting state is:

summary rejected
checkpoint not written
raw RuntimeEvent history kept

That part is working as designed.

Why the next step compacts again

The current failure state is recorded as:

lastShapeFailure = {
  stepNumber,
  detail,
  diagnosticReason,
}

This remembers only which provider step failed. The final-request owner also checks only the current step when deciding whether capacity compaction has already been attempted.

The behavior therefore becomes:

step 1 fails → only step 1 is protected from re-entry
step 2 starts → compaction is eligible again
step 3 starts → compaction is eligible again
step 4 starts → compaction is eligible again

Each new step adds tool calls and tool results, so the covered history prefix grows. Although the failures have the same underlying cause, the implementation treats them as independent step-local attempts.

Why the Turn does not stop at the first failure

Runtime has two different thresholds:

high water = contextWindow - reserve
hard cap   = contextWindow

The reproduction uses:

contextWindow = 10,000
reserve       = 2,000
high water    = 8,000
hard cap      = 10,000

Crossing the high-water threshold starts compaction. If compaction fails but the raw request is still below the hard cap, Runtime continues to the next provider step. The next step grows the request and can trigger compaction again:

cross high water
→ history_compact #1
→ malformed summary
→ fail open and continue

next tool result grows the request
→ history_compact #2
→ malformed summary
→ fail open and continue

...

Only when the final request estimate exceeds the hard cap does Runtime terminate with:

context_budget_exhausted
detail: summarizer_failed

What the reproduction test proves

The test builds a long-running Turn with:

• one Read tool call on each provider step;
• increasing reported input usage on each step;
• a summarizer that always completes but returns an invalid summary;
• 40 potential tool steps, allowing the hard-cap boundary to be reached naturally.

On the current implementation, the result is:

provider requests: 38
history_compact calls: 9
accepted checkpoints: 0
terminal stop reason: context_budget_exhausted
terminal detail: summarizer_failed

This is the same failure shape as the eight repeated compaction attempts reported in this issue. The exact count depends on the fixture and provider usage progression; the important fact is that one Turn can spend multiple summarizer calls without producing any usable checkpoint.

The test also confirms that the safety boundary remains intact:

malformed summaries are never written as checkpoints
canonical RuntimeEvent history is never replaced

This is therefore a liveness problem, not a history-integrity problem.

User impact

1. One Turn can spend multiple additional summarizer requests.
2. Each request can add substantial latency and provider cost.
3. None of those calls produces a usable checkpoint.
4. The user receives no usable context projection to continue from.
5. The final UI outcome is a relatively generic Task run failed / context_budget_exhausted state.
6. A follow-up Turn creates a fresh compaction state and can start trying again.

The retained test is intentionally a characterization test for the current behavior. Once the fix lands, its expectation should change from “9 failed attempts” to “stop after the configured failure budget.”

Proposed solution

Phase 1: bound compaction failures within one Turn

Add a compaction failure budget to the active Turn state. For example, allow at most two non-recoverable compaction failures.

After the budget is exhausted:

• do not call the summarizer again;
• do not write a checkpoint;
• keep the canonical RuntimeEvent history unchanged;
• finish the Turn with stable summarizer_failed context-budget semantics;
• preserve the granular reason, such as malformed_summary_missing_section, in diagnostics.

That changes the behavior from:

failure → continue → failure → continue → failure → ...

to:

failure → one bounded retry → failure → stable termination

Phase 2: actionable recovery guidance

Desktop and TUI can map the stable terminal reason to explicit recovery guidance:

• configure the model's real context window;
• switch model or connection;
• start a fresh task or branch.

Phase 3: cross-Turn and restart-persistent lineage

Cross-Turn failure fingerprints require a deliberate boundary because a new Turn adds new user messages and RuntimeEvents. A naïve full-history hash would treat every follow-up as unrelated, while an overly broad latch could prevent legitimate retries after a model or context-window change.

That persistence and lineage work should follow the smaller in-Turn bound rather than being mixed into the first fix.

简体中文摘要

测试代码已经保留，目前只修改了 Runtime 测试夹具，没有修改生产代码，也没有创建 commit。复现测试和 Runtime build 都已通过。

Maka 的历史压缩不是删除历史，而是生成 checkpoint 投影。摘要通过校验后才能写入 checkpoint；摘要失败时保留原始 RuntimeEvent，这个安全边界是正确的。

真正的问题是 fail open 没有失败预算。当前失败记录只绑定 lastShapeFailure.stepNumber，所以它只能阻止同一个 provider step 重入。下一步工具调用让历史前缀继续增长后，新的 step 又可以发起 compaction。

复现测试中，一个 Turn 持续产生工具调用，input usage 逐步增加，summarizer 始终返回缺少必需章节的非法摘要。当前结果是 38 次 provider 请求、9 次 history_compact、0 个有效 checkpoint，最后以 context_budget_exhausted / summarizer_failed 结束。这和 issue 中同一 Turn 连续 8 次失败是同类行为。

因此这是活性问题，不是历史完整性问题：坏摘要没有覆盖真实历史，但 Runtime 在没有进展的情况下反复消耗 summarizer 请求。

建议第一阶段只增加当前 Turn 的有界 compaction failure budget。达到上限后不再调用 summarizer，保持原始历史和严格校验不变，以稳定的 summarizer_failed 终止，并保留详细诊断。Desktop/TUI 的恢复提示，以及跨 Turn / 重启持久化的 failure lineage，作为后续切片处理。

[somewan820]

English

The fix is ready for maintainer review in #3751.

The implementation keeps the strict checkpoint validator unchanged and closes the liveness loop at three levels:

• the default summarizer gets exactly one stricter repair attempt after a malformed_summary_* result, so persistent malformed output is bounded at two physical provider calls;
• a Turn-level latch prevents later provider steps from invoking compaction again after that malformed-summary budget is exhausted;
• a bounded Session-backend fingerprint cache prevents an identical malformed compaction input from being redispatched in later Turns. A changed source history, model, connection, context-budget configuration, or request shape remains eligible.

The cross-Turn circuit is intentionally in memory on the reused Session backend. Backend invalidation or app restart clears it, which also permits a retry after connection/model/settings repair without introducing durable failure-lineage state in this patch.

The granular reason, for example malformed_summary_missing_section, now survives the RuntimeEvent -> failed Runtime Host Turn snapshot -> Desktop error projection. Runtime Host compatibility epoch moves from 48 to 49, and Desktop recommends checking the declared context window, switching models, or starting a new task instead of suggesting a byte-identical retry.

Local build, lint, format, typecheck, knip, the protocol epoch guard, and all focused regression suites pass. The concurrent root test run hit three unrelated timing/process tests; all three passed when rerun in isolation, and the affected Runtime and Desktop workspaces passed in the root run.

AI assistance disclosure: Codex inspected the incident and repository, implemented the patch and tests, ran verification, and drafted this update. The commit carries a Generated-by: Codex trailer.

简体中文

修复已经提交到 #3751，等待 maintainer review。

实现保留了严格的 checkpoint 摘要校验，没有降低安全边界，并从三层关闭活性问题：

• 默认摘要器在遇到 malformed_summary_* 后只进行一次更严格的修复，因此持续输出坏摘要时，真实 provider 调用最多两次；
• 当前 Turn 的 latch 会在坏摘要预算耗尽后阻止后续 provider step 再次触发压缩；
• Session backend 内保存一个有界失败指纹缓存，后续 Turn 不会再次发送完全相同的坏压缩输入。源历史、模型、连接、上下文预算配置或 request shape 变化后仍允许重试。

跨 Turn 熔断有意保持为复用 Session backend 上的内存状态。backend 失效或应用重启会清空它，这样更换连接、模型或修复设置后可以自然重试，本补丁也不需要引入持久化失败 lineage。

细粒度原因（例如 malformed_summary_missing_section）现在会从 RuntimeEvent 一直保留到 Runtime Host 的失败 Turn snapshot，再投影到 Desktop 错误事件。Runtime Host compatibility epoch 从 48 提升到 49；Desktop 不再建议原样重试，而是提示检查模型声明的上下文窗口、切换模型或开启新任务。

本地 build、lint、format、typecheck、knip、协议 epoch guard 和全部重点回归测试均通过。根目录并发全量测试遇到 3 条无关的时序/进程测试失败，但三条单独重跑都通过；本次受影响的 Runtime 和 Desktop 工作区在根测试中均通过。

AI 协助披露：Codex 检查了事故与仓库，实现了补丁和测试，执行了验证，并起草了本次更新。提交中包含 Generated-by: Codex trailer。

[somewan820]

Maintainer checkpoint

Hi @M4n5ter, PR #3751 is ready for maintainer review at exact head cbe797d81.

The review follow-up is complete: the cross-Turn malformed-compaction circuit now has table-driven coverage proving that unchanged input stays blocked while model, connection, context-window budget, and request-shape changes are eligible again. The PR scope remains the Desktop + Runtime Host incident reported here; CLI/TUI detail presentation and the two P3 UX/coverage items are recorded as follow-ups.

The branch is rebased onto main@902d78523, is mergeable, and exact-head CI is green: run 32817681637 (test, 13m57s). Local Runtime verification is also green: 3,058 tests, 3,045 passed, 13 skipped, 0 failed.

I could not submit a formal GitHub review request because fork PR authors do not have RequestReviewsByLogin permission, so I am leaving this explicit checkpoint here.

AI assistance disclosure: Codex implemented and verified the review follow-up and drafted this checkpoint; I verified the result before posting.

简体中文

@M4n5ter，PR #3751 已可进行 maintainer review，当前准确 head 为 cbe797d81。

review follow-up 已完成：新增表驱动回归测试，证明相同输入继续被熔断，而模型、连接、上下文窗口预算或 request shape 变化后会重新允许压缩。本 PR 保持 #3743 的 Desktop + Runtime Host 范围；CLI/TUI 的细分错误展示，以及 review 中两个 P3 的 UX/覆盖项保留为后续。

分支已 rebase 到 main@902d78523，当前可合并，准确 head 的 CI 已通过：run 32817681637（test，13m57s）。本地 Runtime 完整验证同样通过：3,058 tests、3,045 passed、13 skipped、0 failed。

由于 fork PR 作者没有 RequestReviewsByLogin 权限，无法在 GitHub 上正式添加 reviewer，因此在 issue 中留下这条明确 checkpoint。