openclaw - 💡(How to fix) Fix [Bug]: Cron runs finish with status ok but delivery is lost (not-delivered) and gateway throws "Agent listener invoked outside active run" [1 comments, 1 participants]

Summary

OpenClaw cron runs can complete with status: ok but lose their final summary delivery, ending as deliveryStatus: not-delivered and summary: null.

In the same time window, the gateway logs show an unhandled promise rejection:

Error: Agent listener invoked outside active run

This looks like a run-lifecycle / delivery bug rather than a task failure.

Environment

• OpenClaw: 2026.4.5
• Node: 22.22.2
• Gateway service: local systemd-managed gateway
• Runtime model: openai-codex/gpt-5.4
• Surface/channel is not important to reproduce; the problem appears in cron execution + delivery handling

What happened

A cron job that normally posts concise progress updates started showing this pattern:

• earlier run finishes normally and is delivered
• next run finishes with status: ok
• but delivery becomes not-delivered
• summary is missing/null
• manual rerun reproduces the same ok + not-delivered outcome

The underlying task did not crash. The delivery path seems to break after completion.

Minimal evidence

Cron run history

Healthy run:

{"ts":1775547942230,"runAtMs":1775547432863,"status":"ok","delivered":true,"deliveryStatus":"delivered","durationMs":115692,"summary":"PR head is not actionable yet: CI still in progress","sessionId":"f1d557a5-5a8e-4ccf-a6f9-11467c3f71cb"}

Broken scheduled run right after:

{"ts":1775549178490,"runAtMs":1775549100022,"status":"ok","delivered":false,"deliveryStatus":"not-delivered","durationMs":78461,"summary":null,"sessionId":"c27fde38-605a-47f0-8ddc-1717880050f4"}

Broken manual rerun:

{"ts":1775549400150,"runAtMs":1775549330706,"status":"ok","delivered":false,"deliveryStatus":"not-delivered","durationMs":69440,"summary":null,"sessionId":"2ac6804b-2eb9-452f-b3f7-24129c1b9ad8"}

Gateway log error

[openclaw] Unhandled promise rejection: Error: Agent listener invoked outside active run
    at Agent.processEvents (.../@mariozechner/pi-agent-core/src/agent.ts:533:10)
    at .../@mariozechner/pi-agent-core/src/agent.ts:380:21
    at Object.onUpdate (.../@mariozechner/pi-agent-core/src/agent-loop.ts:539:7)
    at emitUpdate (.../dist/exec-defaults-uj0McX2k.js:1524:8)
    at handleStdout (.../dist/exec-defaults-uj0McX2k.js:1546:4)
    at Object.onSupervisorStdout [as onStdout] (.../dist/exec-defaults-uj0McX2k.js:1610:3)

Related warnings seen before/around the failure

lane wait exceeded: lane=session:agent:main:cron:... waitedMs=391829 queueAhead=3

[cron:...] skipping stale delivery scheduled at 2026-04-06T21:05:00.000Z, started 573m late, current age 576m

Why this looks like an OpenClaw bug

Because the agent run itself completes successfully (status: ok) but the result is lost during or after final event handling. The strongest indicator is the unhandled promise rejection complaining that an agent listener is receiving updates after the run is no longer considered active.

That suggests a race / ordering bug in one of these areas:

• agent event listener lifecycle
• cron announce delivery finalization
• supervisor stdout updates arriving after run close
• queue/lane delay interacting badly with run completion state

Impact

• cron jobs appear healthy in run history (status: ok) while user-visible delivery is silently lost
• summaries vanish (summary: null)
• manual reruns may reproduce the same broken delivery path
• this makes cron automation unreliable and hard to trust operationally

Reproduction hypothesis

I do not yet have a tiny standalone reproduction, but the recurring pattern is:

1. Run an isolated cron job that performs non-trivial work and emits progress/final output.
2. Let the session lane be somewhat congested or delayed.
3. Observe successful run completion in JSONL.
4. Observe final delivery dropped with not-delivered and missing summary.
5. Check gateway logs for Agent listener invoked outside active run.

Expected behavior

If a cron run reaches status: ok, OpenClaw should either:

• deliver the final summary successfully, or
• mark the run as a delivery error with a concrete reason, without losing the summary payload

It should not silently convert a successful run into not-delivered with summary: null, and it definitely should not hit an unhandled promise rejection in the gateway.