Repository navigation
[Bug]: Headless automation runs longer than 5 minutes are marked dispatch_failed with error "timeout" #22725
Description
Operating system
Linux (NixOS, x86_64)
Orca version
1.4.207. The same code is on main at 98584332 (2026-09-24), after v1.4.210.
Details
Problem. A terminal-session automation that runs longer than 5 minutes ends with status dispatch_failed and error timeout. This happens even when the agent keeps working and finishes successfully. Every run shorter than 5 minutes ends completed.
Evidence. In orca automations runs --id <automation> --json, each failed run has usage.collectedAt - startedAt equal to 300000 ms (±10 ms). One example: schedulerOwner: local_host_service, sessionKind: terminal, agent omp. The agent ran a command for 5 min 18 s, the command exited 0, and the agent then reported its result. Orca had already recorded dispatch_failed at 300 s.
Cause. In src/main/startup/main-process-automations.ts, the headless dispatcher waits for completion with no timeout of its own:
await runtime.waitForTerminal(terminalHandle, { condition: 'tui-idle' })The terminal wait therefore uses its default, TUI_IDLE_DEFAULT_TIMEOUT_MS = 5 * 60 * 1000. When that limit expires, the wait rejects with Error('timeout'), and the completion .catch in the dispatch flow records { status: 'dispatch_failed', error: 'timeout' }.
The separate completion observer (observeCompletion) already treats timeout as retryable for up to 6 h ("Orca stopped watching this run after 6h without a completion signal"). The headless path does not use it, so it gets the 5-minute limit.
Expected. A headless automation run should be observed like other runs: retry on timeout up to the 6 h limit, or pass an explicit long timeoutMs. A run should not end dispatch_failed while its agent is still working.
Workaround. None in automation settings. orca automations create/edit offers only --precheck-timeout.
Activity
leilei3167 commentedon Sep 24, 2026
Taking a look at the headless tui-idle wait — it looks like the 5-minute default is cutting off long runs before the agent finishes. I'll put up a small fix so that path retries timeouts the same way the completion observer does.
oldwinter commentedon Oct 13, 2026
Looks fixed in 1.4.224, at least on a paired Linux runtime (
orca serve, headless, local_host_service schedules):dispatch_failed/timeoutat startedAt + 300 s (36 Codex, 8 pi). Only 1 of 21 completed Codex runs lasted more than 300 s.timeoutwas recorded about 6 h before the update.In v1.4.224,
src/main/automations/runtime-automation-service.ts(added in #24863) no longer gives headless launches a completion promise ("No completion: the run's watcher observes it, retrying wait timeouts until it settles").src/main/startup/main-process-automations.tsno longer callswaitForTerminal(…, { condition: 'tui-idle' })with the 5-minute default. That seems to supersede #22731. Unless the desktop path still has the 5-minute wait, this issue and #22731 can probably be closed as fixed in 1.4.224.OrcaWin commentedon Oct 15, 2026
Fixed by #24863 (#24863): headless automation launches no longer await a single tui-idle wait with the 5-minute default; the run watcher retries wait timeouts until the run settles. This shipped in v1.4.224, confirmed above with 0 timeouts across 86 runs. Please reopen if a run still ends dispatch_failed / timeout at 300 s.