Long-running operations

Generation and test runs do work in cloud sandboxes:

• Generation (generate_feature) — minutes, consumes AI credits.
• Runs (run_feature) — duration depends on the tests and target.

The dispatch returns an id after admission rather than waiting for the operation to finish. Admission and model selection can themselves take time; accepted work normally returns 202.

The pattern

1. Dispatch work once and keep the returned id.
2. Poll its read endpoint. Generation and test runs expose isTerminal, terminalReason, and recommendedPollAfterSeconds.
3. If generation reports awaitingInput, answer the pending question rather than dispatching again.
4. Read the final result only after completion. Missing data or an interrupted status read is not a failed test.

Coverage scans and coverage runs are also asynchronous. Track the returned scan/run identity through their documented read endpoints. A coverage runActive flag by itself is not a success verdict.

Let the tooling wait for you

Surface	Convenience
MCP	wait_for_run / wait_for_generation — poll from the local MCP process at the recommended interval (normally 3 s); timeoutSeconds default 120, max 170.
CLI	testvibe run … --wait, testvibe generate … --watch. Re-arms the 170 s wait for you until the work is terminal, bounded by one --timeout <seconds> budget for the whole command (default 5400, 0 = indefinitely, env TESTVIBE_WAIT_TIMEOUT_SECONDS).

info

Timeout ≠ failure. If a wait_* tool returns while the work is still in flight, nothing was cancelled — call it again to keep waiting. Configure your MCP client timeout to accommodate the wait interval and HTTP requests.

The CLI says the same thing with an exit code: a --wait/--watch that hits its ceiling exits 3 — no verdict, explicitly distinct from 1 (something failed). Full table in the CLI wait contract.

Generation can be terminal without the feature row having caught up; use isTerminal, not featureStatus alone. wait_for_generation returns early for awaitingInput. The CLI generate <feature> --watch dispatches first, so reconnect with REST/MCP status reads, or use generate answer … --watch when answering a parked question. Honor the dispatch retry and idempotency rules.