Problem

Fixes #10564

The cron scheduler relies solely on setTimeout to trigger job execution. If the timer is silently lost — due to macOS sleep/wake, GC pause, process throttling, or any other runtime disruption — no recovery mechanism exists. The missed job slot is never executed until an external API call (e.g. cron list) happens to call ensureLoaded → recomputeNextRuns → armTimer.

Observed behavior: A cron job scheduled for 7:00 AM PST (0 7-19 * * 1-5) did not fire until manually triggered 2+ hours later. Gateway logs showed the timer was correctly armed after job creation but never fired, likely due to macOS power management suspending the Node.js event loop during sleep.

Solution

Clamp the maximum setTimeout delay in armTimer() to 60 seconds via DRIFT_GUARD_MAX_DELAY_MS. This means:

• When a job is due in <60s: timer fires at the exact due time (no change)
• When a job is due in >60s: timer fires every 60s, onTimer() finds no overdue jobs, does nothing, and re-arms
• When a timer was lost (sleep/wake): the next 60s wake catches the overdue job within at most 1 minute

This is simpler and more robust than a separate setInterval drift guard:

• No second timer to manage or leak
• No interaction issues with fake timers in tests
• Same setTimeout + re-arm pattern already used by the scheduler
• Minimal overhead (~1 timer wake/minute when idle)

Changes

• src/cron/service/timer.ts: Add DRIFT_GUARD_MAX_DELAY_MS = 60_000 constant, clamp delay in armTimer()
• src/cron/service.drift-guard-catches-overdue-jobs.test.ts: Two new tests validating the drift guard behavior

Test Results

All 60 tests pass (58 existing + 2 new):

 Test Files  14 passed (14)
      Tests  60 passed (60)

Greptile Overview

Greptile Summary

• Adds a drift-guard to the cron scheduler by clamping setTimeout delays in armTimer() to a maximum of 60s, so overdue jobs can be detected even if the original timer was lost (sleep/GC/throttling).
• Introduces DRIFT_GUARD_MAX_DELAY_MS and updates timer arming to use the minimum of computed delay, Node’s max timeout, and the drift-guard cap.
• Adds two Vitest tests that simulate timer loss and validate that the scheduler re-arms and eventually runs overdue jobs, while not executing far-future jobs early.

Confidence Score: 4/5

• This PR is generally safe to merge; the core timer change is small and the added tests cover the intended drift-guard behavior.
• The change is localized to clamping the timer delay and is backed by new tests that exercise overdue-job recovery and far-future behavior. The main outstanding concern is test resource cleanup patterns that can leak temp dirs/timers on assertion failure, which can cause flakiness in CI or local runs.
• src/cron/service.drift-guard-catches-overdue-jobs.test.ts

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