fix(cron): re-arm timer when onTimer rejects unexpectedly

[suboss87]

Closes openclaw#73166

Problem

When onTimer rejects unexpectedly (e.g. a transient error thrown from inside the finally block's armTimer call due to Node.js internals or GC pressure), the .catch() handler in armTimer's setTimeout callback only logs the error. No new timer is registered, permanently breaking the scheduler chain with no recovery path until the next gateway restart.

Root cause

src/cron/service/timer.ts — the setTimeout callback inside armTimer:

state.timer = setTimeout(() => {
  void onTimer(state).catch((err) => {
    state.deps.log.error({ err: String(err) }, "cron: timer tick failed");
    // Missing: armTimer(state) re-arm
  });
}, clampedDelay);

If onTimer rejects, the catch block logs but does not re-arm. state.timer is left as null (set to null at the top of armTimer before the throw).

Fix

Call armTimer(state) inside the .catch() handler so the scheduler chain survives an unexpected rejection.

Regression test

Added to src/cron/service.armtimer-tight-loop.test.ts: makes nowMs() throw on the 4th call (inside the finally block's armTimer), which causes onTimer to reject. Verifies that log.error is called and state.timer is non-null after the .catch() re-arm. All 4 tests in the file pass.

---

Generated by Claude Code

---

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 3 additional findings in Devin Review.

[devin-ai-integration]

🟡 armRunningRecheckTimer's .catch() doesn't re-arm, leaving scheduler vulnerable to the same permanent death the PR aims to fix

The PR adds re-arm logic in armTimer's .catch() handler (lines 553-559) to prevent permanent scheduler death when onTimer rejects unexpectedly. However, armRunningRecheckTimer at src/cron/service/timer.ts:572-576 has the same void onTimer(state).catch(...) pattern without the re-arm fix. If onTimer is called from armRunningRecheckTimer's callback with state.running = false (possible via a race where the watchdog fires at the same event-loop tick that the primary onTimer completes), and armTimer throws in onTimer's finally block (line 736), the .catch() at line 573-574 only logs the error without re-arming. At that point, armRunningRecheckTimer's callback cleared the timer that armTimer had set (line 597 calls armRunningRecheckTimer which clears state.timer), and the finally block's armTimer cleared the watchdog before throwing (line 508-509). No active timer remains, permanently killing the scheduler chain — the exact failure mode this PR intends to prevent.

(Refers to lines 572-576)

---

Was this helpful? React with 👍 or 👎 to provide feedback.