openclaw - 💡(How to fix) Fix Bug: Cron jobs silently removed during config reload — distinct from shutdown race (#37605, #25363) [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash) — cron jobs silently removed during runtime config reload, not during shutdown.

Summary

A successfully-created cron job was removed by the Gateway before any SIGTERM or restart signal. The timing suggests the config-reload pipeline itself is triggering cron: job removed, and the job is not recovered after the subsequent restart. This is a different trigger path from the known shutdown-race issues (#37605, #25363).

Steps to reproduce

1. Have multiple channels configured (e.g., weixin + telegram + whatsapp)
2. Attempt cron.add with delivery: {mode: "none"} — fails because delivery.channel is required when multiple channels are configured
3. Fix and retry cron.add with a delivery.channel specified — succeeds
4. Within ~6 minutes, a config change occurs (e.g., from another session) triggering [reload] config change detected
5. The reload pipeline emits [gateway] cron: job removed before SIGTERM
6. Gateway restarts → jobs.json is empty → job permanently gone

Timeline (exact log timestamps, Asia/Shanghai, 2026-05-06)

10:24:14  ❌ cron.add failed — "delivery.channel is required when multiple
           channels are configured: openclaw-weixin, telegram, whatsapp"
10:24:33  ✅ [gateway] cron: job created
10:30:41  🗑️  [gateway] cron: job removed   ← 6 min later, BEFORE any restart
10:30:56  [reload] config change detected; evaluating reload (update)
10:31:08  [gateway] signal SIGTERM received
10:31:08  [gateway] received SIGTERM; restarting

Key observations:

• cron: job removed at 10:30:41 is 15 seconds before the config reload is detected
• It is 27 seconds before SIGTERM
• This is NOT a shutdown flush race — the Gateway was running normally and chose to remove the job

Expected behavior

Cron jobs that were successfully created should not be removed during normal operation. Config reloads should not clear cron state.

Actual behavior

1. Job was silently removed during runtime (no error, no alert)
2. After restart, jobs.json was completely empty (all jobs gone)
3. jobs.json.bak correctly retained the full job configuration
4. User only discovered the loss 24h later when the scheduled task didn"t fire

Additional finding

The initial failed cron.add (delivery.channel validation error) may leave partial/dirty state that interacts poorly with the subsequent reload. The sequence: failed add → successful add → config reload → job removed is worth investigating for residual state.

Recovery suggestion

jobs.json.bak preserved the correct job config. The Gateway could check jobs.json.bak on startup as a recovery mechanism when jobs.json is empty or corrupted.

Environment

• OpenClaw: 2026.5.4 (325df3e)
• OS: macOS 25.4.0 arm64
• Node: v24.15.0
• Channels configured: openclaw-weixin, telegram, whatsapp (at time of incident)

Related

• #37605 — Cron jobs lost during gateway restart (race condition in persistence) [locked]
• #25363 — Cron jobs lost during rapid gateway restarts
• #6460 — Cron jobs do not persist across gateway restarts

Impact and severity

• Silent data loss with no recovery mechanism
• Scheduled automation (daily update check) missed entirely
• No alert generated despite failureAlert being configured
• Difficult to detect — user must actively check cron list or notice missed executions
• The jobs.json.bak recovery path exists but is unused