Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix cron job nextRunAtMs reset to 0 when editing jobs via openclaw cron edit [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63499•Fetched 2026-04-09 07:53:03
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Author
DY991dyDY991dy
Participants
DY991dyDY991dyWarrenJonesWarrenJones
Timeline (top)
commented ×1cross-referenced ×1

Error Message

Manually recalculate and write nextRunAtMs after each edit. This is fragile and error-prone.

Fix Action

Workaround

Manually recalculate and write nextRunAtMs after each edit. This is fragile and error-prone.

PR fix notes

PR #63507: fix(cron): repair nextRunAtMs=0 on non-schedule edits

Description (problem / solution / changelog)

Closes #63499

Summary

  • treat nextRunAtMs <= 0 as invalid during non-schedule cron job updates
  • editing metadata fields like --description now recomputes nextRunAtMs instead of silently keeping a corrupt/zero value
  • add two regression tests covering both the preservation case and the repair case

Root cause

The update() function in src/cron/service/ops.ts only repaired nextRunAtMs when it was undefined or non-finite. A value of 0 passed both guards (typeof 0 === "number" and Number.isFinite(0)), so it was silently preserved. Once nextRunAtMs became 0 (from any source — initialization bug, concurrent write, or store corruption), every subsequent non-schedule edit would keep it at 0, causing the cron scheduler to treat the job as stale and skip delivery.

Test plan

  • node scripts/run-vitest.mjs run --config vitest.cron.config.ts src/cron/service/ops.test.ts — 7 passed (including 2 new)

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/cron/isolated-agent/delivery-dispatch.double-announce.test.ts (modified, +20/-0)
  • src/cron/isolated-agent/delivery-dispatch.ts (modified, +2/-3)
  • src/cron/service.issue-13992-regression.test.ts (modified, +16/-0)
  • src/cron/service/jobs.ts (modified, +13/-8)
  • src/cron/service/ops.test.ts (modified, +79/-1)
  • src/cron/service/ops.ts (modified, +3/-7)
  • src/cron/service/timer.ts (modified, +5/-13)

Code Example

[cron:54e331d4-44ad-4919-90ac-23fb4b5ace22] skipping stale delivery 
scheduled at 2026-04-08T00:00:00.000Z, started 459m late, current age 466m
RAW_BUFFERClick to expand / collapse

Bug Description

Every time a cron job is edited via openclaw cron edit, its nextRunAtMs is reset to 0, causing incorrect scheduling and stale delivery skips.

Steps to Reproduce

  1. Create a cron job (e.g., 0 9 * * * daily at 9 AM)
  2. Observe that nextRunAtMs is correctly set (e.g., 1775782800000 → next day 09:00 Beijing)
  3. Edit the job using openclaw cron edit <id> --description "test"
  4. Check jobs.json — nextRunAtMs is now 0

Expected Behavior

Editing a job should preserve nextRunAtMs or correctly recalculate it. The nextRunAtMs represents when the job should run next — editing configuration fields (like description) should not reset this.

Actual Behavior

  • nextRunAtMs becomes 0
  • OpenClaw then schedules the job as if it should run immediately
  • Delivery system sees "stale" delivery (scheduled time in the past) and skips it
  • All subsequent deliveries for that job fail silently

Evidence

Gateway log shows:

[cron:54e331d4-44ad-4919-90ac-23fb4b5ace22] skipping stale delivery 
scheduled at 2026-04-08T00:00:00.000Z, started 459m late, current age 466m

The job was supposed to run at 8 AM but was treated as scheduled at 00:00:00 UTC (i.e., nextRunAtMs=0).

Affected Jobs

All cron jobs are affected — every time any field is edited, nextRunAtMs resets to 0.

Workaround

Manually recalculate and write nextRunAtMs after each edit. This is fragile and error-prone.

Environment

  • OpenClaw version: 2026.4.1 (da64a97)
  • Platform: macOS
  • Node.js: v24.13.1

Suggested Fix

When editing a job via openclaw cron edit, preserve the existing nextRunAtMs unless the cron expression itself was changed. If the cron expression changed, recalculate nextRunAtMs based on the new expression.

extent analysis

TL;DR

Preserve the existing nextRunAtMs when editing a cron job unless the cron expression itself was changed, and recalculate it if the expression changed.

Guidance

  • Verify that the nextRunAtMs is being reset to 0 after editing a cron job by checking the jobs.json file.
  • Check the cron job editing logic to ensure it handles the nextRunAtMs field correctly, preserving its value unless the cron expression is modified.
  • Consider adding a validation step after editing a cron job to ensure nextRunAtMs is correctly set, either by preserving the original value or recalculating it based on the new cron expression.
  • Review the Gateway log for similar errors to identify any other jobs that may be affected by this issue.

Example

No specific code snippet can be provided without more context, but the fix should involve modifying the openclaw cron edit command to handle nextRunAtMs correctly.

Notes

The provided workaround of manually recalculating and writing nextRunAtMs after each edit is fragile and error-prone, highlighting the need for a more robust solution.

Recommendation

Apply a workaround to preserve nextRunAtMs when editing cron jobs, as a permanent fix may require modifications to the openclaw cron edit command logic.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#vector store#embedding generation#cache error#pipeline error#runtime error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING