wait_for_run
Block until the run finishes, polling at the server-recommended interval (normally 3 seconds), and return its results digest.
This is an MCP / CLI convenience — there is no REST wait endpoint. Over raw HTTP, poll GET …/runs/{runId} yourself. See Long-running operations.
Arguments
| Argument | Type | Required | Description |
|---|---|---|---|
runId | integer | yes | The run id from run_feature. |
timeoutSeconds | integer | no | How long to wait (default 120, max 170). |
project | string | no | Project public id (defaults to the configured project). |
- MCP
- CLI
Tool wait_for_run — { "runId": 214 }.
testvibe run "Login Functionality" --wait --timeout 900
--wait re-arms this wait until the run is terminal, so you don't call it in a loop yourself. --timeout bounds the whole thing (default 5400 s); hitting it exits 3 — no verdict, not a failure. See the CLI wait contract.
Result
The same payload as get_run, taken when isTerminal becomes true — or at the timeout.
Timing out cancels nothing. If isTerminal is false (queued, allocating, or running), call the tool again with the same runId.
monitoringInterrupted: true means a transient status read failed; it is not a completed result. Retry monitoring the same operation instead of dispatching it again. A wait can finish before the operation, so always check isTerminal on the returned payload.