Repository navigation
orchestration ask: --timeout-ms is silently clamped to 30 min (ORCHESTRATION_ASK_MAX_TIMEOUT_MS); not documented in --help #30372
Description
Version: Orca 1.4.229, macOS, local runtime.
What happens. out/shared/orchestration-ask-timeout.js sets ORCHESTRATION_ASK_MAX_TIMEOUT_MS = 1_800_000, and clampOrchestrationAskTimeoutMs applies Math.min. So an unanswered orca orchestration ask --timeout-ms 14400000 returns after 1800000 ms with:
ask timeout after 1800000ms; question is still pending (messageId: msg_…). Resume waiting; do not ask again:
orca orchestration ask --from <handle> --resume msg_… --timeout-ms 1800000
The output reports the effective timeout, but nothing says up front that the requested value was cut. Neither ask --help nor the orchestration skill mentions the cap.
Why it matters. Workers waiting on a human decision (hours) pass a long --timeout-ms, believe they are covered, and then hit repeated timeouts and resumes.
Ask.
- State the 30-minute maximum in
ask --helpand in the skill's worker-contract reference. - Warn, or reject, when
--timeout-msexceeds it.
Metadata
Metadata
Assignees
Labels
No labels
Activity
AmethystLiang commentedon Oct 18, 2026
looking into it
nwparker commentedon Oct 23, 2026
Thanks @raucous for the clear report and the exact source pointers. #32044 covers both parts of the ask:
orca orchestration ask --helpnow documents the range (1 to 1800000 ms, default 600000). The orchestration skill's worker-contract reference explains the 30-minute cap and says to resume the same question after a timeout.--timeout-msabove 1800000 is now rejected up front withinvalid_argument(exit 1) instead of being silently clamped, and no question is created.Server-side clamping is unchanged, so older CLIs behave as before. Closing as fixed. cc @AmethystLiang since you were looking into this.