Summary

• Problem: Legacy cron jobs created by older versions may still store schedule.cron and jobId, while current runtime expects schedule.expr and id, causing schedule evaluation errors and silent non-firing jobs.
• Why it matters: Existing production cron jobs can stop running right after upgrade, with users seeing no expected deliveries.
• What changed: Added load-time store migration in src/cron/service/store.ts for jobId -> id, schedule.cron -> schedule.expr, and canonical wakeMode; added defensive fallback for legacy cron field in src/cron/schedule.ts; normalized legacy schedule.cron in src/cron/normalize.ts; added regression tests.
• What did NOT change: No new cron syntax, no scheduler cadence changes beyond legacy-field compatibility.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: Ineffective monitoring for failing cron jobs #28861

User-visible / Behavior Changes

• Legacy jobs that still use schedule.cron now migrate automatically and continue running.
• Legacy jobs with jobId now normalize to id during load.
• Missing/invalid wakeMode on legacy records defaults to now during migration.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS 26.3 (dev), legacy repro from Ubuntu/docker issue report
• Runtime: Node.js + pnpm workspace tests
• Integration/channel: Cron service

Steps

1. Prepare a legacy jobs.json entry with schedule: { kind: "cron", cron: "*/5 * * * *" } and jobId instead of id.
2. Start cron service and list jobs.

Expected

• Job is loaded with canonical fields (id, schedule.expr) and keeps scheduling.

Actual

• Before fix: schedule evaluation could fail due to missing expr, and legacy fields were not normalized.
• After fix: legacy fields are migrated on load and scheduling proceeds normally.

Evidence

• Added regression tests:
  • src/cron/service.store-migration.test.ts
  • src/cron/schedule.test.ts
  • src/cron/normalize.test.ts
• Test run:
  • pnpm --dir /Users/sidqin/Desktop/openclaw-contrib exec vitest src/cron/service.store-migration.test.ts src/cron/schedule.test.ts src/cron/normalize.test.ts
  • Result: 3 files passed, 41 tests passed.

Human Verification (required)

• Verified scenarios:
  • Legacy store record with schedule.cron migrates to schedule.expr.
  • Legacy jobId migrates to canonical id.
  • Runtime schedule computation accepts legacy cron field defensively.
• Edge cases checked:
  • Existing canonical expr remains preferred.
  • Missing wakeMode is normalized consistently.
• What I did not verify:
  • Full end-to-end cron delivery against external chat providers in a live deployment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No (automatic load-time migration)

Failure Recovery (if this breaks)

• How to disable/revert: Revert this commit or redeploy previous build.
• Files/config to restore: src/cron/service/store.ts, src/cron/schedule.ts, src/cron/normalize.ts.
• Known bad symptoms: Legacy cron records may fail to fire again after rollback.

Risks and Mitigations

• Risk: Mutating legacy store data on load can touch many records in one pass.
• Mitigation: Migration is deterministic, narrow in scope, and covered by focused regression tests.