Greptile Summary

This PR fixes two independent root causes that caused isolated cron agentTurn jobs to hang until the full timeout rather than failing fast or surviving model fallbacks.

Fix 1 — Per-attempt AbortController (src/cron/isolated-agent/run.ts): The shared parent AbortSignal was previously forwarded directly to runEmbeddedPiAgent. When the timeout fired mid-attempt, subsequent fallback attempts received the already-aborted parent signal and bailed out instantly. Each attempt now gets its own AbortController linked to the parent via a { once: true } listener; the finally block removes the listener cleanly. Logic and cleanup are correct.

Fix 2 — Deferred execution timeout (src/cron/service/timer.ts): The job-level timeout timer previously started immediately in Promise.race, allowing lane-queue wait time to consume the execution budget before real work began. The timer is now armed via an onExecutionStart callback called inside executeJobCore just before runIsolatedAgentJob. A 2× safety backstop ensures the race never hangs if onExecutionStart is never reached (e.g., early validation failure). Idempotency (armed flag) and cleanup (finally) are handled correctly.

Both fixes are logically sound, properly scoped, and well-tested with 5 new regression tests covering deferred timeout behavior, onExecutionStart ordering, and abort signal propagation. All 502 existing cron tests pass.

Confidence Score: 4/5

• Safe to merge — both fixes are logically correct and thoroughly tested with 5 new tests plus all 502 existing tests passing.
• The PR implements two well-scoped, independent fixes for isolated cron timeout hangs. The deferred execution timeout correctly arms the timer only after onExecutionStart is called, preventing queue-wait time from consuming the budget. The per-attempt AbortController logic is clean: each fallback attempt gets a fresh controller linked to the parent signal with proper cleanup. The 5 new tests validate core behavior: timeout deferral, onExecutionStart ordering, and abort signal propagation. Score is held at 4 rather than 5 primarily due to the first test not simulating an actual queue-wait scenario—while the test still validates happy-path behavior, the specific queue-wait regression case (job waiting in lane queue for 50ms before execution) lacks explicit automated coverage.
• No files require special attention. Core logic in both timer.ts and run.ts is correct.

_{Last reviewed commit: f6818f3}

Heavily impacted by both issues described here — wanted to add a field report.

We have several isolated agentTurn cron jobs running on a busy gateway with multiple agents (main, forge, governance). The combination of the shared AbortController and the non-deferred timeout created a compounding failure mode today: cron lane saturation caused lane waits long enough to burn through a significant portion of the job's timeout budget before execution even started. When the first attempt was aborted (by the now-expired timer), the poisoned signal cascaded to all fallback attempts, producing FailoverError: LLM request timed out across the entire fallback chain simultaneously.

The result looked like a provider outage — multiple agents hitting FailoverError at the same moment — even though interactive sessions on the same gateway were unaffected. Took several hours and an external forensic pass to correctly attribute the cause.

Workaround we landed on: pin the cron model to the agent's primary model to avoid triggering the fallback chain at all. Not ideal but stable.

Looking forward to this merging. Happy to provide test data or a reproduction config if useful.

Hi @tyler6204 @vincentkoc — this PR has been CI-green and Greptile 4/5 ("safe to merge") for a few days now. We also got a field report from another user confirming the real-world impact (see spectra-the-bot's comment above), and a duplicate issue #42632 was independently filed. A competing PR #41796 was closed in favour of this approach. Would appreciate a review when you get a chance 🙏

I’ve been hitting this issue quite frequently as well, so really appreciate the work that’s already gone into this fix.

I noticed the PR has been open for a while and seems technically mature already. Just wondering if there are any blockers at the moment that are holding up the merge?

Happy to help validate this against our production workload if needed.

@vincentkoc @tyler6204

Please don’t spam-ping multiple maintainers at once. Be patient, or join our community Discord for help: https://discord.gg/clawd

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

Close as superseded: current main has already shipped the deferred-timeout fix, while this PR's timer hook still arms too early and the remaining abort/fallback semantics are now tracked by narrower follow-up work.

So I’m closing this here and keeping the remaining discussion on the canonical linked item.