You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "somewan820 (via GitHub)" <gi...@apache.org> on 2026/08/25 02:28:22 UTC

[I] fix(runtime): malformed compaction summaries can permanently strand a session [maka]

somewan820 opened a new issue, #3743:
URL: https://github.com/apache/maka/issues/3743

   ## 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 #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:
   
   ```text
   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:
   
   ```text
   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:
   
   - #3029 added the safety-critical malformed-summary validator. This issue keeps that invariant and addresses the resulting dead-end recovery path.
   - #3372 documented real `malformed_summary_missing_section` completions as an out-of-scope compaction defect in a separate image-budget incident.
   - #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._
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org


Re: [I] fix(runtime): malformed compaction summaries can permanently strand a session [maka]

Posted by "somewan820 (via GitHub)" <gi...@apache.org>.
somewan820 commented on issue #3743:
URL: https://github.com/apache/maka/issues/3743#issuecomment-5404585919

   <details open>
   <summary><strong>English</strong></summary>
   
   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._
   
   </details>
   
   <details>
   <summary><strong>简体中文</strong></summary>
   
   修复已经提交到 #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。_
   
   </details>
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org


Re: [I] fix(runtime): malformed compaction summaries can permanently strand a session [maka]

Posted by "somewan820 (via GitHub)" <gi...@apache.org>.
somewan820 commented on issue #3743:
URL: https://github.com/apache/maka/issues/3743#issuecomment-5406642521

   <details open>
   <summary><strong>Maintainer checkpoint</strong></summary>
   
   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](https://github.com/apache/maka/actions/runs/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._
   
   </details>
   
   <details>
   <summary><strong>简体中文</strong></summary>
   
   @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](https://github.com/apache/maka/actions/runs/32817681637)(`test`,13m57s)。本地 Runtime 完整验证同样通过:3,058 tests、3,045 passed、13 skipped、0 failed。
   
   由于 fork PR 作者没有 `RequestReviewsByLogin` 权限,无法在 GitHub 上正式添加 reviewer,因此在 issue 中留下这条明确 checkpoint。
   
   </details>


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org


Re: [I] fix(runtime): malformed compaction summaries can permanently strand a session [maka]

Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han closed issue #3743: fix(runtime): malformed compaction summaries can permanently strand a session
URL: https://github.com/apache/maka/issues/3743


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org


Re: [I] fix(runtime): malformed compaction summaries can permanently strand a session [maka]

Posted by "testikun (via GitHub)" <gi...@apache.org>.
testikun commented on issue #3743:
URL: https://github.com/apache/maka/issues/3743#issuecomment-5404497884

   > *This was generated by AI during triage.*
   
   ## Verification
   
   I checked the reported behavior against the current compaction implementation and reproduced the liveness failure with a deterministic injected summarizer; no real provider credentials or live model call were required.
   
   The malformed-summary regression added for [#3029](https://github.com/apache/maka/issues/3029) predates this issue and is already present in `main@3a9824a7e`. That test still proves the safety invariant:
   
   - an incomplete summary is rejected as `malformed_summary_missing_section`;
   - no invalid checkpoint is written;
   - canonical RuntimeEvent history remains intact.
   
   The new characterization test uses a long-running Turn that emits one tool call per provider step. The mock provider reports increasing input usage, while the summarizer completes normally but omits the required checkpoint sections. The current implementation produced:
   
   - 38 provider requests;
   - 9 `history_compact` calls;
   - 0 accepted checkpoints;
   - terminal `context_budget_exhausted` with detail `summarizer_failed`.
   
   This is the same failure shape as the reported eight repeated compaction attempts. The exact count is test-fixture dependent; the important result is that the same Turn can spend multiple summarizer calls without making progress.
   
   ## Root cause
   
   The strict validator correctly fails open and keeps the raw history. However, the failure latch is scoped to the current provider step through `lastShapeFailure.stepNumber`. When the next tool step grows the history prefix, the next step is eligible to invoke compaction again. The hard-cap verdict only stops the Turn after the final request estimate is over the model capacity, so several failed compaction calls can occur while the request is still below that hard cap.
   
   Each new `send` also creates a fresh `MidTurnCapacityCompactState`, so a follow-up starts with no in-memory record of the previous failed attempts. A follow-up adds new RuntimeEvents, so its source prefix is not byte-identical; this is why the cross-Turn retry policy needs a deliberate boundary rather than a naïve full-history hash.
   
   ## Proposed first implementation slice
   
   1. Add a bounded compaction-failure budget to the active Turn state.
   2. Count non-recoverable summarizer failures such as malformed sections, provider failure, and checkpoint write failure.
   3. Once the budget is exhausted, stop invoking the summarizer for that Turn and finish with the stable `summarizer_failed` context-budget outcome.
   4. Preserve the existing safety rules: no malformed checkpoint is written, and canonical RuntimeEvents are never replaced.
   5. Keep the granular failure reason in diagnostics so the UI can later offer actionable recovery: configure the real context window, switch model/connection, or start a fresh task/branch.
   
   Cross-Turn and restart-persistent failure lineage can be handled as a follow-up slice after the bounded in-Turn behavior is agreed. The current reproduction establishes the missing bound without requiring any change to the summary validator.
   
   <details>
   <summary>简体中文摘要</summary>
   
   我核对了当前 compaction 实现,并用注入式 summarizer 做了确定性复现,不需要真实 provider 凭据或线上模型请求。
   
   为 [#3029](https://github.com/apache/maka/issues/3029) 增加的 malformed-summary 回归测试早于本 issue,`main@3a9824a7e` 已经包含它。该测试证明安全边界仍然有效:非法摘要会被识别为 `malformed_summary_missing_section`,不会写入 checkpoint,原始 RuntimeEvent 历史不会被覆盖。
   
   新的复现测试让一个 Turn 持续产生工具调用,让 provider 报告逐步增加的 input usage,同时让 summarizer 正常完成但缺少必需章节。当前实现得到 38 次 provider 请求、9 次 `history_compact`、0 个有效 checkpoint,最终以 `context_budget_exhausted / summarizer_failed` 结束。这和 issue 中同一 Turn 连续 8 次失败是同类行为,具体次数取决于测试夹具,关键是失败压缩会在没有进展的情况下被重复调用。
   
   根因是失败保护只绑定当前 provider step 的 `lastShapeFailure.stepNumber`。下一次工具 step 让历史前缀变长后,又会获得一次新的 compaction 资格;只有最终请求超过 hard cap 时才会停止。每个新的 `send` 还会重新创建 `MidTurnCapacityCompactState`,因此 follow-up 会重新开始尝试。
   
   建议第一阶段只增加当前 Turn 的有界失败预算:达到上限后不再调用 summarizer,保持原始历史和严格校验不变,以稳定的 `summarizer_failed` 终止,并保留详细诊断。跨 Turn / 重启持久化的 failure lineage 和 UI 恢复提示可以作为后续切片。
   
   </details>
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org