openclaw - 💡(How to fix) Fix Memory Dreaming Promotion cron can timeout repeatedly without tracked success state [1 comments, 2 participants]

Summary

The managed Memory Dreaming Promotion cron appears to be a special systemEvent job that can repeatedly time out without normal tracked freshness/finalize semantics, which makes cron health look degraded even when the rest of the cron system is healthy.

Environment

• OpenClaw CLI/package: 2026.4.21
• Gateway runtime: 2026.4.21
• Host: Linux

What I observed

Job definition from ~/.openclaw/cron/jobs.json:

• name: Memory Dreaming Promotion
• id: a948fe88-4b04-4951-9624-5d6de89758c7
• payload.kind: systemEvent
• payload.text: __openclaw_memory_core_short_term_promotion_dream__
• delivery.mode: none

State from ~/.openclaw/cron/jobs-state.json:

• lastRunStatus: error
• lastStatus: error
• lastDurationMs: 600202
• lastDeliveryStatus: not-requested
• consecutiveErrors: 5
• lastErrorReason: timeout
• lastError: cron: job execution timed out

Why this seems like an OpenClaw bug / gap

Other cron jobs can be normalized to the current contract (delivery.mode: none, ClankerHive claim/fact/finalize, intentional silent success). This one is different:

• it is a managed systemEvent, not a normal agent-turn wrapper job
• it does not expose the same fact/finalize path as normal tracked jobs
• when it times out, cron health surfaces it as a repeated error with no obvious recovery/visibility path

This makes it hard to distinguish:

1. a genuinely broken memory-promotion engine,
2. a long-running but successful internal promotion flow,
3. or missing/insufficient status accounting for this special job kind.

Expected

One of:

• the managed memory-promotion cron should complete within timeout and record successful state cleanly, or
• the platform should expose clearer tracked state/health semantics for managed systemEvent cron jobs, or
• the job should use a timeout / progress model appropriate for the work so it does not accumulate repeated opaque timeout failures.

Notes

On this host, I separately fixed local cron config drift (many jobs still had delivery.mode: announce instead of none), and after that cleanup the validator passed cleanly. This issue remained the meaningful upstream-looking anomaly.