PR #84083: fix(agents): bound plugin-owned context-engine compaction with a safety timeout

• Repository: openclaw/openclaw
• Author: 100yenadmin
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/84083

Description (problem / solution / changelog)

Summary

A plugin context engine that advertises ownsCompaction: true (e.g. the lossless-claw LCM plugin) had its ContextEngine.compact() awaited by the host with no timeout, no watchdog, and no abort signal on every engine-owned compaction lane — both the built-in pi-embedded runner and the codex agent harness:

• queued /compact (compact.queued.ts)
• context-overflow / force-compaction recovery (run.ts)
• timeout recovery (run.ts)
• context-engine-owned Codex compaction (extensions/codex/.../compact.ts)
• Codex force-compaction-on-overflow recovery (extensions/codex/.../run-attempt.ts)

The 900 s compactWithSafetyTimeout safety net (EMBEDDED_COMPACTION_TIMEOUT_MS) that protects native pi-agent-core compaction was only ever applied to the native activeSession.compact() call. A slow or hung plugin compact() would hang the agent turn indefinitely — the only backstop was the 48 h default run timeout, which could not even interrupt the plugin call. The two codex-harness sites already had a try/catch that converts a thrown compact() error to a clean { ok: false } result, but a hung promise that never settles was not caught.

Changes

• Add a compactContextEngineWithSafetyTimeout helper that wraps a plugin ContextEngine.compact() in the same finite, host-resolved safety timeout used for native compaction.
• Wire it into all five engine-owned contextEngine.compact() call sites:
  • pi-embedded runner — queued /compact (compact.queued.ts), context-overflow recovery and timeout recovery (run.ts).
  • codex agent harness — compactOwningContextEngine (extensions/codex/src/app-server/compact.ts) and forceContextEngineCompactionForCodexOverflow (extensions/codex/src/app-server/run-attempt.ts). These are the lanes a codex-harness agent with an ownsCompaction plugin actually uses.
• Export compactContextEngineWithSafetyTimeout (+ resolveCompactionTimeoutMs) through the existing openclaw/plugin-sdk/agent-harness-runtime surface that the codex extension already imports, so the host and the codex harness share one implementation rather than copy-pasting the watchdog across the package boundary.
• Add an optional abortSignal to the ContextEngine.compact() contract. The run's abort signal is both raced against the call (so a non-cooperating engine is still bounded) and threaded into the compact() params (so cooperating engines can cancel their own in-flight work). The codex sites thread params.abortSignal (compact.ts) and the run-level runAbortController.signal (run-attempt.ts).
• On timeout/abort the queued lane and both codex-harness lanes surface a clean { ok: false } result — matching how the overflow/timeout run lanes already convert a thrown compact() — instead of hanging or throwing a raw rejection at callers.

This is additive to feat/context-engine-intercept-compaction, which covers the separate codex session_before_compact intercept lane (interceptsCompaction); this PR covers the ownsCompaction queued/overflow/timeout lanes across both the pi-embedded runner and the codex harness.

Fixes #84077

Test plan

• pnpm tsgo:core + pnpm tsgo:core:test clean
• pnpm tsgo:extensions + pnpm tsgo:extensions:test clean
• oxlint clean on all changed files; plugin-sdk boundary checks pass
• New unit tests: a plugin compact() exceeding the timeout is bounded and rejects with a timeout error; the abort signal is threaded into compact() params; abort fires before timeout and rejects promptly
• New integration tests: queued lane converts a hung/throwing compact() to a clean ok:false; run abort signal reaches engine-owned overflow compaction
• New codex-harness tests: a hung owning-engine compact() in the Codex compaction lane is bounded and surfaces as ok:false; a hung compact() during Codex overflow recovery is bounded so the run still proceeds; the caller / run-level abort signal is threaded into the codex-harness compact()
• Existing pi-embedded compaction suites pass (118 tests across the 5 affected files); existing codex compaction suites pass

Real behavior proof

Behavior addressed: hung ownsCompaction context-engine compaction no longer waits forever. The host timeout now both bounds the await and aborts the signal passed into contextEngine.compact(), then returns a clean failed compaction result.

Real environment tested: local OpenClaw checkout /Volumes/LEXAR/repos/openclaw-fix-owns-compaction-timeout, branch fix/owns-compaction-safety-timeout, head b5a35b16b55, Node via node --import tsx, actual extensions/codex/src/app-server/compact.ts and src/agents/pi-embedded-runner/compaction-safety-timeout.ts.

Exact steps or command run after the patch: created a real Codex app-server session binding under /Volumes/LEXAR/Codex/pr-84083-proof, supplied an owning context engine whose compact() never settles, configured agents.defaults.compaction.timeoutSeconds=1, invoked maybeCompactCodexAppServerSession(), and captured whether the signal delivered to compact() aborted when the safety timeout fired.

Evidence after fix:

{
  "branch": "fix/owns-compaction-safety-timeout",
  "head": "b5a35b16b55",
  "behavior": "hung ownsCompaction contextEngine.compact() receives a host timeout abort signal and returns bounded failure",
  "elapsedMs": 1088,
  "compactCalls": 1,
  "receivedAbortSignal": true,
  "signalAborted": true,
  "signalReason": "Compaction timed out",
  "result": {
    "ok": false,
    "compacted": false,
    "reason": "context engine compaction failed: Compaction timed out"
  }
}

Observed result after fix: the hung owning engine returned through the host safety timeout in about 1.1 seconds, the engine saw an AbortSignal, that signal aborted with Compaction timed out, and the caller received { ok: false, compacted: false } instead of hanging.

What was not tested: a real third-party plugin process wedged in production; this proof uses the in-process context-engine interface with an intentionally never-settling compact() implementation.

Changed files

• CHANGELOG.md (modified, +1/-0)
• docs/.generated/plugin-sdk-api-baseline.sha256 (modified, +2/-2)
• extensions/codex/src/app-server/compact.test.ts (modified, +108/-11)
• extensions/codex/src/app-server/compact.ts (modified, +23/-11)
• extensions/codex/src/app-server/run-attempt.context-engine.test.ts (modified, +93/-0)
• extensions/codex/src/app-server/run-attempt.ts (modified, +27/-15)
• src/agents/command/cli-compaction.test.ts (modified, +85/-0)
• src/agents/command/cli-compaction.ts (modified, +26/-10)
• src/agents/pi-embedded-runner.compaction-safety-timeout.test.ts (modified, +128/-0)
• src/agents/pi-embedded-runner/compact.hooks.harness.ts (modified, +23/-5)
• src/agents/pi-embedded-runner/compact.hooks.test.ts (modified, +27/-0)
• src/agents/pi-embedded-runner/compact.queued.ts (modified, +39/-11)
• src/agents/pi-embedded-runner/compaction-safety-timeout.ts (modified, +84/-3)
• src/agents/pi-embedded-runner/run.overflow-compaction.test.ts (modified, +20/-0)
• src/agents/pi-embedded-runner/run.ts (modified, +45/-21)
• src/context-engine/types.ts (modified, +12/-0)
• src/plugin-sdk/agent-harness-runtime.ts (modified, +9/-0)

PR #84153: fix(plugins): add default timeout for before_compaction/after_compaction hooks

• Repository: openclaw/openclaw
• Author: 100yenadmin
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/84153

Description (problem / solution / changelog)

Bug

DEFAULT_VOID_HOOK_TIMEOUT_MS_BY_HOOK in src/plugins/hooks.ts listed only agent_end. The before_compaction and after_compaction plugin hooks are void hooks (runBeforeCompaction / runAfterCompaction → runVoidHook(...)), and runVoidHook applies a timeout only when getVoidHookTimeoutMs returns a value. With no table entry and no plugin-supplied hook.timeoutMs, both hooks ran fully unbounded.

In the codex agent harness these hooks fire on the serialized notification queue — extensions/codex/src/app-server/event-projector.ts handleItemStarted awaits runAgentHarnessBeforeCompactionHook (and the matching after_compaction call site) for a contextCompaction item. A slow or hung compaction hook therefore freezes processing of every later codex notification — including turn/completed — so the whole agent turn hangs.

Fix

Add before_compaction and after_compaction entries to DEFAULT_VOID_HOOK_TIMEOUT_MS_BY_HOOK, mirroring the defensive-default pattern already applied to agent_end. The budget is 30s, matching agent_end (the closest like-for-like precedent — a void lifecycle hook) rather than the tighter 15s modifying-hook defaults, because compaction hooks can legitimately do real work such as a memory flush. The runner is fail-open for void hooks, so a timed-out handler is logged and compaction proceeds without it.

A plugin can still override the default per-registration via hook.timeoutMs.

Related

Related to #84077 — the same compaction-stall investigation. That issue covers the host's missing safety timeout on plugin-owned compact(); this is a separate, independent mechanism (unbounded void hooks freezing the codex notification queue), hence "Related" rather than "Fixes".

Test plan

• pnpm tsgo:core and pnpm tsgo:core:test — typecheck passes
• oxlint on changed files — 0 warnings / 0 errors
• New src/plugins/hooks.compaction-timeout.test.ts:
  • a never-settling before_compaction handler is bounded by the default timeout (no override) and logged, rather than hanging
  • same for after_compaction
  • a fast before_compaction handler completes without a false-positive timeout
• vitest (plugins project): new tests + hooks.correlation.test.ts + wired-hooks-compaction.test.ts — 15/15 pass

Real behavior proof

Behavior addressed: hung plugin before_compaction and after_compaction handlers no longer stall compaction forever. The hook runner now applies the default fail-open timeout when no per-hook override is configured.

Real environment tested: local OpenClaw checkout /Volumes/LEXAR/repos/openclaw-fix-compaction-hook-timeout, branch fix/compaction-hook-default-timeout, Node via node --import tsx, actual src/plugins/hooks.ts plugin hook runner.

Exact steps or command run after the patch: ran a live script that registers a plugin whose before_compaction and after_compaction hooks never settle, then invokes runHookTimeout for both hooks without per-hook timeout overrides.

Evidence after fix:

{
  "branch": "fix/compaction-hook-default-timeout",
  "behavior": "hung before_compaction and after_compaction hooks return via default fail-open timeout",
  "elapsedMs": 30033,
  "eventCount": 2,
  "events": [
    "[hooks] before_compaction handler from live-proof-plugin failed: timed out after 30000ms",
    "[hooks] after_compaction handler from live-proof-plugin failed: timed out after 30000ms"
  ]
}

Observed result after fix: both hung hook handlers returned through the default timeout path in about 30 seconds each, emitted fail-open timeout events, and did not block the caller indefinitely.

What was not tested: a real external plugin process wedged in production; the proof uses the in-process hook runner with intentionally never-settling handlers.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/plugins/hooks.compaction-timeout.test.ts (added, +121/-0)
• src/plugins/hooks.ts (modified, +12/-0)

PR #356: Scout: Critical Inherited Defect Report - 2024-05-19

• Repository: MillionthOdin16/openclaw
• Author: MillionthOdin16
• State: open | merged: False
• Link: https://github.com/MillionthOdin16/openclaw/pull/356

Description (problem / solution / changelog)

🦅 Scout: Critical Inherited Defect Report - 2024-05-19

• Upstream Issue #84077: Plugin-owned context engines run compaction with no safety timeout
• Location in our code:
  • src/agents/pi-embedded-runner/compact.ts line 942
  • src/agents/pi-embedded-runner/run.ts line 1030
• Observed Behavior: When a context engine plugin that owns compaction is asked to compact the session, OpenClaw awaits the contextEngine.compact() call without any timeout, watchdog, or abort signal. If the plugin's compaction process hangs (e.g., due to rate limits or infinite loops), the agent turn stalls indefinitely because the 900s safety timeout is only applied to native compaction.
• Expected Behavior: The contextEngine.compact() call must be wrapped in a safety timeout (e.g., using compactWithSafetyTimeout or compactContextEngineWithSafetyTimeout) across all call sites to ensure the agent turn can recover or fail cleanly if the plugin engine hangs.

PR created automatically by Jules for task 9358273685489953605 started by @MillionthOdin16

Summary by CodeRabbit

• Documentation
  • Documented a known issue where certain operations could hang without proper safety controls, potentially affecting agent responsiveness. Mitigation recommendations included.

Changed files

• .jules/scout.md (added, +4/-0)