Greptile Summary

This PR replaces the fixed 2-hour STUCK_RUN_MS constant with a per-job stuck-lock threshold (resolveCronJobTimeoutMs(job) + 5-minute buffer), so jobs with shorter execution timeouts no longer have to wait 2 hours for a stale lock to be cleared after an unclean shutdown.

Key changes:

• STUCK_RUN_MS (2 h) removed; replaced with STUCK_RUN_BUFFER_MS (5 min) added on top of each job's resolved timeout, and STUCK_RUN_FALLBACK_MS (30 min) used when the timeout resolver returns undefined.
• resolveCronJobTimeoutMs is now imported into jobs.ts and called per-job on every timer tick that has a runningAtMs marker.
• Four new regression tests added covering the custom-timeout clearing path, the preserve-within-threshold path, and the systemEvent vs agentTurn comparison.

Potential concern: STUCK_RUN_FALLBACK_MS = 30 min applies to any job where resolveCronJobTimeoutMs returns undefined — specifically agentTurn jobs with timeoutSeconds ≤ 0 (i.e. explicitly disabled execution timeout). Before this PR those jobs used the 2-hour window; after this PR they use 30 minutes. A job that legitimately runs longer than 30 minutes with no execution timeout will have its runningAtMs lock cleared by the maintenance tick, leaving it eligible to run again while the original execution is still in progress. The PR description calls this intentional, but the scenario is worth careful validation against real-world timeoutSeconds: 0 usage in production.

Confidence Score: 3/5

• Mostly safe to merge for standard jobs; needs validation for production use of timeoutSeconds: 0 or negative values before merging.
• The implementation is correct and well-tested for the primary use-cases (jobs with positive timeoutSeconds or using the platform defaults). The new tests are mathematically sound. However, the STUCK_RUN_FALLBACK_MS = 30 min fallback represents a silent regression for jobs configured with timeoutSeconds ≤ 0 — their stuck window drops from 2 hours to 30 minutes, increasing the risk of duplicate concurrent executions for any such job that legitimately runs past 30 minutes. If no production jobs use timeoutSeconds ≤ 0, the risk is low; if they do, this could cause real double-execution bugs.
• Pay close attention to src/cron/service/jobs.ts lines 44-48 (STUCK_RUN_FALLBACK_MS) and any callers that may create agentTurn jobs with timeoutSeconds: 0 or negative values.

This is a comment left during a code review.
Path: src/cron/service/jobs.ts
Line: 44-48

Comment:
**Fallback threshold may clear locks for indefinitely-running jobs**

`STUCK_RUN_FALLBACK_MS = 30 min` applies to any job where `resolveCronJobTimeoutMs` returns `undefined` — which happens when `timeoutSeconds <= 0`. A user who sets `timeoutSeconds: 0` to mean "no execution timeout" (i.e. the job is allowed to run indefinitely) will now have their lock cleared after 30 minutes, down from the previous 2-hour default.

If such a job is legitimately running past the 30-minute mark, `normalizeJobTickState` will clear `runningAtMs`, `isJobDue` will see no lock, and the job can be scheduled again — producing a duplicate concurrent execution that the lock was specifically meant to prevent.

Before this PR, the fixed `STUCK_RUN_MS = 2h` applied uniformly, so an indefinite-timeout job had a 2-hour safety window. The PR's intent of tightening things is sound, but this particular edge case swings in the wrong direction: the one class of jobs most likely to run long (those with `timeoutSeconds ≤ 0`) now gets the *shortest* fallback threshold.

Consider using a larger fallback (e.g. the old `STUCK_RUN_MS = 2h`) specifically for `undefined`-timeout jobs, or documenting clearly that `timeoutSeconds: 0` should not be used with long-running jobs.

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

_{Last reviewed commit: 82d454b}

Fixed the P2 (clamp stuck threshold): clamped stuckThresholdMs to Math.min(jobTimeout + buffer, STUCK_RUN_FALLBACK_MS) so absurdly large timeoutSeconds values that overflow setTimeout's 2^31-1 ms limit degrade to the 2-hour fallback instead of leaving stuck locks for days.