This is a comment left during a code review.
Path: src/cron/service/ops.ts
Line: 25-27

Comment:
**Duplicate of private helper in `jobs.ts`**

`isFiniteTimestamp` is already defined as a private helper in `src/cron/service/jobs.ts` (line 83–85) with the identical implementation. Since it isn't exported there, a local copy is needed here — but it may be worth exporting the one from `jobs.ts` and importing it to avoid the duplication and keep the guard logic in sync if it ever changes.

```suggestion
// Consider exporting isFiniteTimestamp from jobs.ts and importing here
function isFiniteTimestamp(value: unknown): value is number {
  return typeof value === "number" && Number.isFinite(value);
}
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: src/cron/service/ops.ts
Line: 142-155

Comment:
**Heuristic may be misleading for long-interval schedules**

The condition `nextRun - lastRun > 24 * 60 * 60 * 1000` will always be true for any job whose schedule interval is longer than 24 hours (e.g. a weekly or monthly cron job), causing `computeJobNextRunAtMs` to be called on every gateway restart for those jobs. In practice this is harmless — `computeJobNextRunAtMs` is deterministic and will return the same value that is already stored, so `updated !== nextRun` keeps the guard from applying an incorrect change — but it produces unnecessary log lines and makes the intent of the heuristic harder to reason about.

The comment also says "if the gateway was down for multiple days, `nextRunAtMs` might have been set to a time that's already passed", but that scenario is already fully handled by `runMissedJobs` + `recomputeNextRuns` above. What this loop actually targets is a stale *future* `nextRunAtMs` (set too far ahead by a prior bug) that `recomputeNextRuns` intentionally skips because `now < nextRunAtMs`. Tightening the comment (and optionally the guard) to reflect this would make the intent clearer:

```suggestion
      // Guard: if nextRunAtMs is more than a day past what the current schedule
      // would produce from lastRunAtMs, the stored value was likely set incorrectly
      // (e.g. by a prior bug) and recomputeNextRuns() won't fix it because it
      // preserves still-future values.  Recompute so the job fires at the correct slot.
      if (nextRun - lastRun > 24 * 60 * 60 * 1000) {
        const updated = computeJobNextRunAtMs(job, now);
        if (isFiniteTimestamp(updated) && updated !== nextRun) {
          job.state.nextRunAtMs = updated;
          state.deps.log.info(
            { jobId: job.id, oldNextRun: nextRun, newNextRun: updated },
            "cron: corrected stale nextRunAtMs after restart",
          );
        }
      }
```

How can I resolve this? If you propose a fix, please make it concise.