openclaw - ✅(Solved) Fix [Feature]: Add `--dry-run` / preview mode to `openclaw cron add` to validate schedule expressions before committing [1 pull requests, 1 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#59452Fetched 2026-04-08 02:25:01
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
Participants
Timeline (top)
referenced ×2cross-referenced ×1

When creating a cron job with openclaw cron add, there is no way to preview what the resolved schedule will look like before it is committed. This is especially problematic for:

  • --at HH:MM (ambiguous time-only strings — see #59441)
  • --at + --tz combinations (timezone conversion is easy to get wrong)
  • Complex cron expressions (--cron) where the next-fire-times are non-obvious

Error Message

This workflow is error-prone and leaves a window where a misconfigured job could fire unexpectedly.

Root Cause

Cron expressions and timezone-aware datetimes are well-known footguns. A dry-run mode turns a "hope this is right" workflow into a "I verified this" workflow. Most CI/CD tools (GitHub Actions, crontab.guru, etc.) provide this kind of preview.

Fix Action

Fixed

PR fix notes

PR #59490: feat(cli): add --dry-run flag to cron add

Description (problem / solution / changelog)

Summary

Adds a --dry-run flag to openclaw cron add that validates and previews the schedule without persisting it to the cron store.

Motivation

Users frequently want to verify that a cron expression or --at time string parses correctly before committing it. Without --dry-run, the only way to check is to add a cron job, inspect it, then delete it.

Behavior

  • --dry-run prints the resolved schedule (human-readable by default, JSON with --json) and exits without writing to the cron store
  • All validation still runs — invalid expressions are rejected before the dry-run output is shown
  • Pipe-friendly: output is routed through the runtime printer helper for consistent behavior when piped (| head -5, etc.)

Edge Cases Handled

  • --dry-run without required fields → validation still runs, error shown normally
  • --dry-run --json → raw JSON output, no decorative text
  • Pipe termination (openclaw cron add ... --dry-run | head -5) → handled by runtime printer

Testing

Tests use vi.spyOn(defaultRuntime, "writeStdout") / vi.spyOn(defaultRuntime, "writeJson") to capture output — this matches the runtime output path used by the implementation and follows the pattern established in logs-cli.test.ts.

Related

Closes #59452

Changed files

  • src/cli/cron-cli/register.cron-add.test.ts (added, +111/-0)
  • src/cli/cron-cli/register.cron-add.ts (modified, +12/-0)

Code Example

# Show what the job WOULD look like without creating it
openclaw cron add --name "daily-summary" --at "00:00" --tz "Asia/Shanghai" --dry-run

---

[DRY RUN] Cron job preview:
  Name:        daily-summary
  Schedule:    one-shot at 2026-04-03 00:00:00 Asia/Shanghai
  UTC:         2026-04-02 16:00:00 UTC
  Next fire:   2026-04-03 00:00:00 +08:00 (in ~10h 39m)
  
Schedule is valid. Run without --dry-run to create.

---

Next 3 fires:
    2026-04-03 09:00:00 +08:00
    2026-04-04 09:00:00 +08:00
    2026-04-05 09:00:00 +08:00
RAW_BUFFERClick to expand / collapse

Summary

When creating a cron job with openclaw cron add, there is no way to preview what the resolved schedule will look like before it is committed. This is especially problematic for:

  • --at HH:MM (ambiguous time-only strings — see #59441)
  • --at + --tz combinations (timezone conversion is easy to get wrong)
  • Complex cron expressions (--cron) where the next-fire-times are non-obvious

Real-World Scenario

While creating a daily summary job with --at 00:00 --tz Asia/Shanghai, I could not verify whether the resolved UTC time was correct before the job was committed. The only way to check was to:

  1. Create the job
  2. Inspect jobs.json directly
  3. Manually calculate whether the UTC offset was correct
  4. Delete and recreate if wrong

This workflow is error-prone and leaves a window where a misconfigured job could fire unexpectedly.

Proposed Behavior

# Show what the job WOULD look like without creating it
openclaw cron add --name "daily-summary" --at "00:00" --tz "Asia/Shanghai" --dry-run

Expected output:

[DRY RUN] Cron job preview:
  Name:        daily-summary
  Schedule:    one-shot at 2026-04-03 00:00:00 Asia/Shanghai
  UTC:         2026-04-02 16:00:00 UTC
  Next fire:   2026-04-03 00:00:00 +08:00 (in ~10h 39m)
  
  ✓ Schedule is valid. Run without --dry-run to create.

For recurring jobs (--cron):

  Next 3 fires:
    2026-04-03 09:00:00 +08:00
    2026-04-04 09:00:00 +08:00
    2026-04-05 09:00:00 +08:00

Why This Matters

Cron expressions and timezone-aware datetimes are well-known footguns. A dry-run mode turns a "hope this is right" workflow into a "I verified this" workflow. Most CI/CD tools (GitHub Actions, crontab.guru, etc.) provide this kind of preview.

extent analysis

TL;DR

Implement a --dry-run flag for openclaw cron add to preview the resolved schedule before committing the job.

Guidance

  • Add a --dry-run option to the openclaw cron add command to display a preview of the job's schedule without creating it.
  • Modify the command's output to include the resolved UTC time and next fire time for easy verification.
  • Consider adding support for displaying the next few fire times for recurring jobs (--cron).
  • Test the --dry-run feature with various input combinations, including --at and --tz options, to ensure accurate previews.

Example

openclaw cron add --name "daily-summary" --at "00:00" --tz "Asia/Shanghai" --dry-run

Expected output:

[DRY RUN] Cron job preview:
  Name:        daily-summary
  Schedule:    one-shot at 2026-04-03 00:00:00 Asia/Shanghai
  UTC:         2026-04-02 16:00:00 UTC
  Next fire:   2026-04-03 00:00:00 +08:00 (in ~10h 39m)
  
  Schedule is valid. Run without --dry-run to create.

Notes

The proposed --dry-run feature aims to mitigate errors caused by ambiguous time-only strings and timezone conversion issues. However, its effectiveness depends on accurate implementation and thorough testing.

Recommendation

Apply the workaround by implementing the --dry-run flag, as it provides a clear and safe way to preview and verify cron job schedules before creation.

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING