openclaw - 💡(How to fix) Fix Telegram inbound dispatch aborts when preflight compaction hits missing Codex thread

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Telegram inbound dispatch can fail during reply-resolver preflight compaction when the stored Codex thread id is stale/missing. The inbound message is accepted by the Telegram channel, but dispatch exits with:

Error: Preflight compaction required but failed: thread not found: <codex-thread-id>

No assistant run starts for that inbound message. The expected recovery would be to clear/replace the stale thread binding, start a fresh Codex thread/session path, or otherwise continue dispatch after missing-thread recovery.

This appears distinct from the general Telegram silent/hang issues because the failure is explicit and occurs before the run starts, with sessionId=unknown and source=replyResolver.

Error Message

Error: Preflight compaction required but failed: thread not found: <codex-thread-id>

Root Cause

This appears distinct from the general Telegram silent/hang issues because the failure is explicit and occurs before the run starts, with sessionId=unknown and source=replyResolver.

Fix Action

Fix / Workaround

Behavior bug (inbound channel dispatch aborts before assistant run starts)

Telegram inbound dispatch can fail during reply-resolver preflight compaction when the stored Codex thread id is stale/missing. The inbound message is accepted by the Telegram channel, but dispatch exits with:

No assistant run starts for that inbound message. The expected recovery would be to clear/replace the stale thread binding, start a fresh Codex thread/session path, or otherwise continue dispatch after missing-thread recovery.

Code Example

Error: Preflight compaction required but failed: thread not found: <codex-thread-id>

---

<timestamp> [telegram] Inbound message telegram:group:<redacted-chat-id> -> @<bot> (group, image/jpeg, 46 chars)
<timestamp> [diagnostic] message dispatch completed: channel=telegram sessionId=unknown sessionKey=agent:main:telegram:group:<redacted-chat-id> source=replyResolver outcome=error duration=22546ms error="Error: Preflight compaction required but failed: thread not found: <codex-thread-id>"
<timestamp> [diagnostic] message processed: channel=telegram chatId=telegram:<redacted-chat-id> messageId=<redacted-message-id> sessionId=unknown sessionKey=agent:main:telegram:group:<redacted-chat-id> outcome=error duration=22643ms error="Error: Preflight compaction required but failed: thread not found: <codex-thread-id>"
<timestamp> [telegram] dispatch failed: Error: Preflight compaction required but failed: thread not found: <codex-thread-id>

---

<timestamp> [telegram] Inbound message telegram:group:<redacted-chat-id> -> @<bot> (group, 16 chars)
<timestamp> [diagnostic] message dispatch completed: channel=telegram sessionId=unknown sessionKey=agent:main:telegram:group:<redacted-chat-id> source=replyResolver outcome=error duration=5115ms error="Error: Preflight compaction required but failed: thread not found: <codex-thread-id>"
<timestamp> [telegram] dispatch failed: Error: Preflight compaction required but failed: thread not found: <codex-thread-id>
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (inbound channel dispatch aborts before assistant run starts)

Summary

Telegram inbound dispatch can fail during reply-resolver preflight compaction when the stored Codex thread id is stale/missing. The inbound message is accepted by the Telegram channel, but dispatch exits with:

Error: Preflight compaction required but failed: thread not found: <codex-thread-id>

No assistant run starts for that inbound message. The expected recovery would be to clear/replace the stale thread binding, start a fresh Codex thread/session path, or otherwise continue dispatch after missing-thread recovery.

This appears distinct from the general Telegram silent/hang issues because the failure is explicit and occurs before the run starts, with sessionId=unknown and source=replyResolver.

Environment

  • OpenClaw version: 2026.5.22
  • Install method: npm global
  • Runtime: Node 22
  • OS: Linux
  • Channel: Telegram group
  • Plugins active: browser, codex, memory-core, telegram
  • Codex transport: managed app-server / embedded run path

Steps to reproduce

Exact deterministic reproduction is not yet known, but the observed sequence was:

  1. A Telegram group-bound main agent accumulated a long enough conversation history to require preflight compaction.
  2. The stored Codex thread id referenced by the reply resolver was no longer available.
  3. A new Telegram inbound message arrived.
  4. OpenClaw accepted the inbound message, then reply-resolver preflight compaction failed with thread not found.
  5. Dispatch returned outcome=error; no assistant run started for that inbound.

Expected behavior

If preflight compaction hits a missing Codex thread, OpenClaw should recover instead of aborting inbound dispatch. Acceptable recovery behavior could be:

  • clear the stale Codex thread binding and create a fresh thread,
  • retry through the existing missing-thread recovery path,
  • compact from persisted channel/session history without requiring the stale thread,
  • or fall back to a clean session with a visible diagnostic.

The inbound message should not be dropped solely because the previous Codex thread id disappeared.

Actual behavior

The inbound message failed before an assistant run started. Multiple consecutive Telegram messages hit the same error until the session/runtime state was repaired or rotated.

Sanitized log examples:

<timestamp> [telegram] Inbound message telegram:group:<redacted-chat-id> -> @<bot> (group, image/jpeg, 46 chars)
<timestamp> [diagnostic] message dispatch completed: channel=telegram sessionId=unknown sessionKey=agent:main:telegram:group:<redacted-chat-id> source=replyResolver outcome=error duration=22546ms error="Error: Preflight compaction required but failed: thread not found: <codex-thread-id>"
<timestamp> [diagnostic] message processed: channel=telegram chatId=telegram:<redacted-chat-id> messageId=<redacted-message-id> sessionId=unknown sessionKey=agent:main:telegram:group:<redacted-chat-id> outcome=error duration=22643ms error="Error: Preflight compaction required but failed: thread not found: <codex-thread-id>"
<timestamp> [telegram] dispatch failed: Error: Preflight compaction required but failed: thread not found: <codex-thread-id>

Repeated on subsequent inbound messages:

<timestamp> [telegram] Inbound message telegram:group:<redacted-chat-id> -> @<bot> (group, 16 chars)
<timestamp> [diagnostic] message dispatch completed: channel=telegram sessionId=unknown sessionKey=agent:main:telegram:group:<redacted-chat-id> source=replyResolver outcome=error duration=5115ms error="Error: Preflight compaction required but failed: thread not found: <codex-thread-id>"
<timestamp> [telegram] dispatch failed: Error: Preflight compaction required but failed: thread not found: <codex-thread-id>

Impact

Telegram group conversations can appear broken even though the channel receives messages. The user-facing failure is a silent/non-useful failed turn: the inbound is consumed, dispatch errors, and the assistant does not answer until the stale state is repaired or rotated.

Related issues checked

I found related open issues, but none seemed to cover this exact missing-thread/preflight-compaction abort path:

  • #84710: Telegram inbound dispatch hangs after inbound log
  • #84154: Telegram group message recorded but no run dispatched until next message
  • #85520: Telegram real reply intermittently never sent after progress draft
  • #85458: source-level concern around runBoundTurnWithMissingThreadRecovery
  • #85999: provider auth prewarm blocks event loop on startup

The event-loop/prewarm behavior may be supporting context in this incident, but the actionable bug here is missing-thread recovery during reply-resolver preflight compaction.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If preflight compaction hits a missing Codex thread, OpenClaw should recover instead of aborting inbound dispatch. Acceptable recovery behavior could be:

  • clear the stale Codex thread binding and create a fresh thread,
  • retry through the existing missing-thread recovery path,
  • compact from persisted channel/session history without requiring the stale thread,
  • or fall back to a clean session with a visible diagnostic.

The inbound message should not be dropped solely because the previous Codex thread id disappeared.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING