Greptile Summary

This PR fixes a legitimate bug where isolated cron job timeout timers started too early (during queue wait on the shared cron lane), causing jobs to appear to time out immediately upon receiving CPU. The core fix — moving the setTimeout to just before runIsolatedAgentJob and combining signals via AbortSignal.any — is well-structured for isolated jobs.

Key concerns:

• Regression for non-isolated jobs: Replacing executeJobCoreWithTimeout with executeJobCore in runDueJob removes the outer timeout wrapper for all job types, not just isolated ones. Main-session jobs with wakeMode === "now" previously respected the user-configured cronJobTimeoutMs via the abort signal threaded through the heartbeat retry loop; they now always wait up to maxWaitMs (2 min) regardless of configuration.
• Overly broad post-return abort check: After runIsolatedAgentJob resolves, checking combinedAbortSignal.aborted unconditionally returns a timeout error — including for non-timeout upstream aborts — which could silently discard a successful result and misreport the error type for future callers that pass unrelated abort signals.
• The jobTimeoutMs variable declared at line 632 in runDueJob is now only used for logging, which may be confusing since it previously drove enforcement.

Confidence Score: 2/5

• Merge with caution — the fix is correct for isolated jobs but inadvertently removes timeout enforcement for main-session jobs and has inconsistent abort-reason handling.
• The isolated-job timeout fix is sound and solves the reported issue. However, switching runDueJob to call executeJobCore directly (instead of executeJobCoreWithTimeout) is a broader change that silently removes timeout behavior for non-isolated job types in the onTimer path. This is a real behavioral regression for users with main-session jobs that have a configured cronJobTimeoutMs shorter than 2 minutes. Additionally, the abort-reason check at lines 1153–1155 doesn't distinguish between timeout and non-timeout aborts, creating a subtle correctness issue if upstream abort signals are passed with non-timeout reasons. These issues lower confidence enough to warrant fixes before merging.
• src/cron/service/timer.ts — specifically the runDueJob function around line 635 and the post-return abort check at lines 1153–1155

_{Last reviewed commit: d4b80a7}

Addressed the timeout review follow-up in 50dfd02. Main-session due jobs keep the outer timeout, isolated execution timeout now starts when execution actually begins, timer-driven isolated runs keep a separate hard guard, and cron timer delays are clamped to the Node timer max.

Tested locally on the PR head:

• pnpm format:check ✅
• pnpm tsgo ✅
• pnpm build ✅
• pnpm test src/cron/service.issue-regressions.test.ts ✅

This looks like the right fix for the cron-lane queue-wait timeout semantics (isolated timeout starts after execution begins), and the added regression coverage is solid.

Closing in favor of #42482, which addresses both the deferred timeout issue (#41783) and the per-attempt AbortController issue (#37505) in a single comprehensive fix. #42482's broader scope makes it a better solution for the cron timeout problem.