Skip to content

Telegram main session can remain unrecoverable after Codex app-server startup failure #85804

Description

@pfrederiksen

Summary

After Codex app-server startup retries exhausted, a Telegram-backed main session was interrupted. A gateway restart brought the service back, but main-session restart recovery could not resume the interrupted transcript:

[main-session-restart-recovery] marked interrupted main session failed: <telegram-main-session> (transcript tail is not resumable)
[main-session-restart-recovery] main-session restart recovery complete: recovered=0 failed=1 skipped=0

The user-visible symptom was not a clear failure message. The Telegram conversation appeared to stall, then later replies appeared missing or out of context. Manual messages sent through the message tool still worked, so the transport was alive while the agent-session path was unhealthy.

This may be downstream of #83959, but the recovery/user-facing behavior seems distinct enough to track separately.

Version / environment

  • OpenClaw 2026.5.20
  • Telegram group session
  • Codex native/app-server runtime
  • Gateway was restarted after the app-server startup retry loop exhausted

Sanitized timeline

The raw logs contained local paths, account details, and session identifiers; those have been replaced below.

18:49:12 [telegram] [diag] isolated polling spool drain failed (1): ENOENT: no such file or directory, rename '<telegram-ingress-spool>/<message>.json.processing' -> '<telegram-ingress-spool>/<message>.json'

18:49:28 [agent/embedded] codex app-server connection closed during startup; restarting app-server and retrying
18:49:35 [agent/embedded] codex app-server connection closed during startup; restarting app-server and retrying
18:49:42 [agent/embedded] codex app-server connection closed during startup; restarting app-server and retrying
18:49:49 [agent/embedded] codex app-server connection closed during startup; restarting app-server and retrying
18:49:54 [agent/embedded] codex app-server connection closed during startup; retries exhausted
18:49:54 [agents/harness] Codex agent harness failed; not falling back to embedded PI backend
18:49:54 [diagnostic] lane task error: lane=main durationMs=44080 error="Error: codex app-server client is closed"
18:49:54 [diagnostic] lane task error: lane=session:<agent-main-session> durationMs=44093 error="Error: codex app-server client is closed"
18:49:54 Embedded agent failed before reply: codex app-server client is closed

18:50:14 [typing] TTL exceeded (60000ms), auto-stopping typing indicator
18:50:34 [diagnostics/memory] memory pressure: level=warning reason=heap_threshold rssBytes=1534287872 heapUsedBytes=1180158800 thresholdBytes=1073741824

18:51:14 [gateway] draining 2 active task(s) and 1 active embedded run(s) before restart with timeout 30000ms
18:51:44 [diagnostic] wait for active embedded runs timed out: activeRuns=1 timeoutMs=30000
18:51:44 [gateway] active embedded run drain grace reached; aborting active run(s) before restart
18:51:44 [gateway] drain timeout reached; proceeding with restart
18:51:44 openclaw-gateway.service: Consumed 34min 52.081s CPU time, 4.4G memory peak, 0B memory swap peak.

18:52:06 [gateway] ready
18:52:09 [main-session-restart-recovery] marked 1 interrupted main session(s) from stale transcript locks
18:52:23 [main-session-restart-recovery] marked interrupted main session failed: <telegram-main-session> (transcript tail is not resumable)
18:52:23 [main-session-restart-recovery] main-session restart recovery complete: recovered=0 failed=1 skipped=0

Impact

  • The Telegram bot still accepted inbound messages, but the main session did not produce a coherent visible reply.
  • The user saw the assistant as silent or responding out of context.
  • The typing indicator eventually timed out, but no clear recovery/failure notice was sent to the chat.
  • A manual gateway restart restored service, but the interrupted main session was not recoverable.

Expected behavior

If an embedded Codex run fails before reply and the gateway later cannot resume the interrupted main-session transcript, OpenClaw should surface a bounded, sanitized failure/recovery message to the affected chat or reset the session cleanly enough that the next user turn is coherent.

Useful behaviors might include:

  • mark the Telegram main session as needing a fresh turn instead of trying to continue from an unrecoverable transcript tail
  • send a generic visible recovery notice when a chat-bound main session is abandoned after restart
  • avoid leaving typing indicators as the only user-visible signal
  • include enough diagnostic context in logs to distinguish app-server startup failure from transcript recovery failure

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions