Fixes cron jobs by hkirat · Pull Request #3335 · openclaw/openclaw

hkirat · 2026-01-28T13:13:24Z

Cron jobs seems to have broken after #1535

The reason seems to be an early return that was added in the PR above, that would not the system events queue clear if HEARTBEAT.md is empty.

Cron jobs are pushed to system events when executed, and hence the change ensures that if there are pending system events they should be executed irrespective of the heartbeat.md file being empty.

Greptile Overview

Greptile Summary

This PR adjusts the heartbeat runner’s “empty HEARTBEAT.md” early-return behavior so that pending system events (e.g., cron-triggered reminders queued into the per-session system-events queue) still cause a heartbeat run. It adds tests covering the new behavior (run when HEARTBEAT.md is effectively empty but system events exist; still skip when empty and no events).

The change integrates with existing heartbeat logic by checking the session’s system-events queue before applying the cost-saving skip, ensuring cron/system-event delivery isn’t blocked by an empty heartbeat file.

Confidence Score: 4/5

This PR is likely safe to merge and addresses the reported cron/system-events regression with targeted tests.
The functional change is small and well-scoped (only gating the empty-heartbeat skip on presence of queued system events) and is covered by new tests. Main remaining risk is around edge cases where sessionKey resolution could be invalid and hasSystemEvents may throw earlier than before.
src/infra/heartbeat-runner.ts (sessionKey/system-events check edge cases)

_{(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)

hkirat · 2026-01-28T13:20:03Z

Tried inside the terminal and telegram.
Screenshot below from tg. Wasn't working before these changes.

Glucksberg · 2026-01-28T20:56:01Z

This PR may help with several open cron issues:

Issues this could address:

Cron jobs fire repeatedly instead of once #3486 - Cron jobs fire repeatedly instead of once
Cron job with 'at' schedule fires immediately instead of waiting for scheduled time #3220 - Cron job with at schedule fires immediately
Cron job scheduled but never fired during event loop silence #2813 - Cron job scheduled but never fired

Related PRs:

fix: Re-arm cron service timer with a delay if already running to prevent missed events. #2990 - fix: Re-arm cron service timer with a delay
fix(cron): anchor 'every' jobs to lastRunAtMs instead of now #2183 - fix(cron): anchor every jobs to lastRunAtMs

Could you clarify which specific cron bugs this addresses? Would help with issue triage.

hkirat · 2026-01-29T05:46:24Z

This one specifically solves #2323 and potentially #2813

It should not affect #3220 and #3486

greptile-apps

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-03T03:54:50Z

src/infra/heartbeat-runner.ts

+  const { entry, sessionKey, storePath } = resolveHeartbeatSession(cfg, agentId, heartbeat);
+
  // Skip heartbeat if HEARTBEAT.md exists but has no actionable content.
  // This saves API calls/costs when the file is effectively empty (only comments/headers).
-  // EXCEPTION: Don't skip for exec events - they have pending system events to process.
+  // EXCEPTION: Don't skip for exec events or if there are pending system events (from cron, etc.)
  const isExecEventReason = opts.reason === "exec-event";
+  const hasPendingSystemEvents = hasSystemEvents(sessionKey);
  const workspaceDir = resolveAgentWorkspaceDir(cfg, agentId);


[P1] hasSystemEvents(sessionKey) can throw before the heartbeat-file check

hasSystemEvents calls requireSessionKey and will throw if resolveHeartbeatSession returns an empty/invalid sessionKey. Previously the empty-heartbeat-file optimization would just try to read HEARTBEAT.md and could skip cleanly; with this change an invalid/misconfigured session key can now crash the runner before it gets to the try/catch around reading the file.

If this can happen (e.g., malformed heartbeat.session config), consider guarding the check or treating invalid session keys as “no pending events” so heartbeat runner can still proceed/skip predictably.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/infra/heartbeat-runner.ts Line: 463:470 Comment: [P1] `hasSystemEvents(sessionKey)` can throw before the heartbeat-file check `hasSystemEvents` calls `requireSessionKey` and will throw if `resolveHeartbeatSession` returns an empty/invalid `sessionKey`. Previously the `empty-heartbeat-file` optimization would just try to read `HEARTBEAT.md` and could skip cleanly; with this change an invalid/misconfigured session key can now crash the runner before it gets to the try/catch around reading the file. If this can happen (e.g., malformed `heartbeat.session` config), consider guarding the check or treating invalid session keys as “no pending events” so heartbeat runner can still proceed/skip predictably. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-03T03:54:51Z

src/infra/heartbeat-runner.returns-default-unset.test.ts

+      // Enqueue a system event (simulates cron job)
+      resetSystemEventsForTest();
+      enqueueSystemEvent("⏰ Reminder: Check your tasks", { sessionKey });
+
+      replySpy.mockResolvedValue([{ text: "Got your reminder! Checking tasks now." }]);
+      const sendWhatsApp = vi.fn().mockResolvedValue({
+        messageId: "m1",
+        toJid: "jid",
+      });


[P2] Test enqueues a system event but doesn’t assert it was actually consumed

This test verifies the heartbeat runs when events exist, but it doesn’t check that the system-event queue is drained/cleared. A regression where events remain pending (or are processed repeatedly) would still pass. It may be worth asserting queue size/hasSystemEvents(sessionKey) becomes false after runHeartbeatOnce if that’s the intended behavior.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/infra/heartbeat-runner.returns-default-unset.test.ts Line: 1046:1054 Comment: [P2] Test enqueues a system event but doesn’t assert it was actually consumed This test verifies the heartbeat runs when events exist, but it doesn’t check that the system-event queue is drained/cleared. A regression where events remain pending (or are processed repeatedly) would still pass. It may be worth asserting queue size/`hasSystemEvents(sessionKey)` becomes false after `runHeartbeatOnce` if that’s the intended behavior. How can I resolve this? If you propose a fix, please make it concise.

adasowa · 2026-02-03T16:20:34Z

Confirming this fix works! 🎉

I've been running OpenClaw from source with this PR (along with #7077 and #7230) and my cron jobs are now firing correctly.

Specifically, I had cron jobs that were silently failing because:

HEARTBEAT.md was empty (just comments)
Cron was pushing system events
The heartbeat runner was returning early before processing those events

With this fix applied, cron-triggered system events are properly delivered even when HEARTBEAT.md is empty. Tested with both wakeMode: now and wakeMode: next-heartbeat — both work as expected.

Thanks for tracking this down!

Takhoffman · 2026-02-15T00:01:04Z

Hello, we have had a lot of cron fixes go out. Are you still having issues?

hkirat added 2 commits January 28, 2026 18:33

fixed cron jobs

1ea6556

added tests

c3bdae9

Glucksberg mentioned this pull request Jan 28, 2026

Cron jobs fire repeatedly instead of once #3486

Closed

adam91holt mentioned this pull request Feb 2, 2026

fix: process cron job system events during heartbeat execution #7109

Closed

greptile-apps bot reviewed Feb 3, 2026

View reviewed changes

This was referenced Feb 3, 2026

fix: default cron enabled to true when not provided #7077

Closed

fix(cron): handle wrapped and unwrapped job objects in cron.add and cron tool #7230

Closed

DiLescure mentioned this pull request Feb 7, 2026

Cron jobs with sessionTarget 'isolated' never fire automatically #10788

Closed

ayhammouda mentioned this pull request Feb 8, 2026

Cron jobs with sessionTarget=isolated + agentTurn never fire #11994

Open

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fixes cron jobs#3335

Fixes cron jobs#3335
hkirat wants to merge 2 commits intoopenclaw:mainfrom
hkirat:cron-fix

hkirat commented Jan 28, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

hkirat commented Jan 28, 2026

Uh oh!

Glucksberg commented Jan 28, 2026

Uh oh!

hkirat commented Jan 29, 2026

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 3, 2026

Uh oh!

greptile-apps bot Feb 3, 2026

Uh oh!

adasowa commented Feb 3, 2026

Uh oh!

Takhoffman commented Feb 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Comments

Uh oh!

Conversation

hkirat commented Jan 28, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Overview

Greptile Summary

Confidence Score: 4/5

Uh oh!

hkirat commented Jan 28, 2026

Uh oh!

Glucksberg commented Jan 28, 2026

Uh oh!

hkirat commented Jan 29, 2026

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

adasowa commented Feb 3, 2026

Uh oh!

Takhoffman commented Feb 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Comments

hkirat commented Jan 28, 2026 •

edited by greptile-apps bot

Loading