Context
executeTerminalCommand already waits for the command to finish via shell integration (633 sequences). However, TerminalService.waitForTerminalExecuted in apps/vscode-extension/src/services/TerminalService.ts hard-codes a 5-second ceiling:
const maxWaitTime = 5000; // 5 seconds
if (Date.now() - startTime >= maxWaitTime) {
resolve(); // give up and proceed
return;
}For demos that compile code, run test suites, pull containers, etc., 5s is often insufficient. The next action fires while the previous command is still running, so scripted demos need large waitForTimeout buffers that (a) make scripts brittle across machines and (b) waste time when the command finishes quickly.
Proposal
Add an optional waitForExit / waitTimeout field to the executeTerminalCommand step:
- action: executeTerminalCommand
command: cargo build --release
waitTimeout: 120000 # ms; overrides the default 5000 cap
Semantics:
- If
waitTimeout is set, use that value instead of the 5000 constant in waitForTerminalExecuted.
- Still resolve on the 633-signalled completion event, so fast commands return immediately; only long commands fully use the extended budget.
- Default unchanged (5000) to preserve existing behaviour.
An alternative spelling — a boolean waitForExit: true that lifts the cap entirely — would also work; I prefer waitTimeout since unbounded waits can deadlock demos when shell integration mis-reports.
Workaround currently in use
In a live-coding demo for the Reinhardt Rust framework we pre-warm cargo build via executeScript backgrounded with nohup/disown, so the subsequent visible cargo run returns within 5s. This works but adds moving parts (a shell script, a log file, a cache dependency) that a single waitTimeout option would eliminate.
Happy to send a PR if the direction is acceptable.
Context
executeTerminalCommandalready waits for the command to finish via shell integration (633 sequences). However,TerminalService.waitForTerminalExecutedinapps/vscode-extension/src/services/TerminalService.tshard-codes a 5-second ceiling:For demos that compile code, run test suites, pull containers, etc., 5s is often insufficient. The next action fires while the previous command is still running, so scripted demos need large
waitForTimeoutbuffers that (a) make scripts brittle across machines and (b) waste time when the command finishes quickly.Proposal
Add an optional
waitForExit/waitTimeoutfield to theexecuteTerminalCommandstep:Semantics:
waitTimeoutis set, use that value instead of the 5000 constant inwaitForTerminalExecuted.An alternative spelling — a boolean
waitForExit: truethat lifts the cap entirely — would also work; I preferwaitTimeoutsince unbounded waits can deadlock demos when shell integration mis-reports.Workaround currently in use
In a live-coding demo for the Reinhardt Rust framework we pre-warm
cargo buildviaexecuteScriptbackgrounded withnohup/disown, so the subsequent visiblecargo runreturns within 5s. This works but adds moving parts (a shell script, a log file, a cache dependency) that a singlewaitTimeoutoption would eliminate.Happy to send a PR if the direction is acceptable.