Skip to content

fix(cron): ensure timer is armed after job creation#11225

Closed
git-tao wants to merge 1 commit intoopenclaw:mainfrom
git-tao:fix/cron-job-timer-arm-after-add
Closed

fix(cron): ensure timer is armed after job creation#11225
git-tao wants to merge 1 commit intoopenclaw:mainfrom
git-tao:fix/cron-job-timer-arm-after-add

Conversation

@git-tao
Copy link

@git-tao git-tao commented Feb 7, 2026

Problem

Cron jobs created after gateway start may not execute because:

  1. nextRunAtMs might not be computed correctly for the new job
  2. armTimer might exit early without setting up a timer
  3. No logging made these failures invisible

Users report jobs appearing valid (enabled: true) but having lastRun: null indefinitely.

Solution

  1. Defensive recomputation: Call recomputeNextRuns() after adding a job to ensure all jobs have correct nextRunAtMs values

  2. Debug logging in armTimer: When timer is not armed, log why:

    • Scheduler disabled
    • No jobs with nextRunAtMs (with counts for debugging)
  3. Info logging after job add: Confirms:

    • Job ID and name
    • Computed nextRunAtMs
    • Scheduler's next wake time
    • Whether timer was successfully armed

Changes

  • src/cron/service/ops.ts: Added recomputeNextRuns() call and logging after job creation
  • src/cron/service/timer.ts: Added debug logging for early exits in armTimer()

Testing

These changes are additive (logging) and defensive (recompute). They don't change the core logic, just ensure:

  1. Job state is consistent after add
  2. Failures are visible in logs

Related

Fixes #11217

Greptile Overview

Greptile Summary

Changes update the cron scheduler to be more robust when jobs are created after startup. After adding a job, the service now recomputes nextRunAtMs across all jobs, persists the updated store, and logs the newly added job’s computed next run plus whether a timer is armed. The timer arming logic also adds debug logs for early exit cases (scheduler disabled / no jobs with computed nextRunAtMs) and logs when a timer is successfully armed (including whether the delay was clamped).

Confidence Score: 5/5

  • This PR is safe to merge with minimal risk.
  • Edits are localized to cron scheduling and are additive/defensive: recomputing next-run timestamps after job creation and adding debug/info logging around timer arming. No behavior changes were found that would break scheduling; logging and recompute use existing helpers.
  • No files require special attention

(2/5) Greptile learns from your feedback when you react with thumbs up/down!

Context used:

  • Context from dashboard - CLAUDE.md (source)
  • Context from dashboard - AGENTS.md (source)

Problem:
Cron jobs created after gateway start may not execute because:
1. nextRunAtMs might not be computed correctly for the new job
2. armTimer might exit early without setting up a timer
3. No logging made these failures invisible

Solution:
1. Call recomputeNextRuns() after adding a job to ensure all jobs
   have correct nextRunAtMs values (defensive consistency check)
2. Add debug logging in armTimer when timer is not armed (shows why)
3. Add info logging after job add (confirms timer state)

This helps diagnose issues like openclaw#11217 where jobs appear valid but
never execute.

Fixes openclaw#11217
Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 87559aff0b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +80 to +82
// Defensive: recompute all next-run times to ensure consistency
// This handles edge cases where job.state.nextRunAtMs might not be set correctly
recomputeNextRuns(state);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Avoid skipping overdue runs when adding jobs

Calling recomputeNextRuns(state) here recalculates nextRunAtMs for all existing jobs using now, which moves any overdue job (e.g., a job whose nextRunAtMs is in the past due to a paused process or time jump) to its next future interval. That means adding a new job can silently clear a due run that would have fired immediately (since armTimer would otherwise schedule with delay 0), so the missed run never executes. If you want to be defensive for the new job only, consider recomputing/setting nextRunAtMs only for that job or deferring recompute until after overdue jobs are handled.

Useful? React with 👍 / 👎.

@tyler6204
Copy link
Member

Superseded by #11641 (merge commit: 8fae55e). Closing to reduce duplicate PR noise. Please open a new PR only if there is additional scope beyond this fix.

@tyler6204 tyler6204 closed this Feb 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] Cron jobs created after gateway start never execute until restart

2 participants