Summary

Fixes #16841

The executeJob function (used for missed-job recovery, runDueJobs, and manual/forced runs via ops.ts) called executeJobCore directly without any timeout wrapper. Unlike the onTimer batch path which correctly used Promise.race with payload.timeoutSeconds, jobs running through executeJob relied solely on the inner agent timeout from resolveAgentTimeoutMs, which defaults to cfg.agents.defaults.timeoutSeconds and ignores the per-job payload.timeoutSeconds override.

Changes

Added the same Promise.race timeout wrapper to executeJob, reading payload.timeoutSeconds from the job config with DEFAULT_JOB_TIMEOUT_MS (10 min) as the fallback — matching the existing onTimer behavior.

Testing

• Existing cron tests pass (service.issue-regressions, service.rearm-timer-when-running)
• Linter and formatter pass (oxlint + oxfmt)

Greptile Summary

Adds Promise.race timeout wrapper to the executeJob function to respect per-job timeoutSeconds configuration. Previously, jobs executed via executeJob (used for missed-job recovery, manual runs, and forced execution) bypassed the job-level timeout and relied only on the inner agent timeout. This change mirrors the existing timeout logic in onTimer (lines 230-245), applying the same jobTimeoutMs calculation and Promise.race pattern with proper timeout cleanup.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The implementation exactly mirrors the proven timeout pattern from onTimer (lines 230-245), uses the same timeout calculation logic, includes proper cleanup via .finally(), and maintains consistency across both execution paths. The change is minimal, focused, and directly addresses the documented issue.
• No files require special attention

_{Last reviewed commit: d29fc2c}