Long-running operations

Generation and runs are dispatched, not awaited — here's the polling pattern every surface uses.

Two operations do real work in cloud sandboxes and take a while:

• Generation (generate_feature) — minutes, consumes AI credits.

• Runs (run_feature) — typically ~30 seconds.

Neither blocks. The dispatch returns 202 immediately with an id, and you observe progress from there.

The pattern

1

Dispatch

POST …/features/12/run        → 202 { "runId": 214, "featureId": 12 }
POST …/features/12/generate   → 202 { "requestId": "a1b2…", "featureId": 12 }

A dispatch that can't start — feature already generating, tests not generated yet — fails fast with 409 conflict instead.

2

Poll

GET …/runs/214                → { "status": "running", … }
GET …/features/12/generation  → { "featureStatus": "generating", "sections": [...] }

A few seconds between polls is plenty. Runs finish as passed/failed; generation moves the feature to generated/failed/cancelled.

3

Read the outcome

The same GET that told you it finished carries the full result — the run digest or the generation status. For a failed generation, drill into the log.

Let the tooling wait for you

Surface	Convenience
MCP	wait_for_run / wait_for_generation — poll server-side every 3 s; timeoutSeconds default 120, max 170.
CLI	testvibe run … --wait, testvibe generate … --watch.

Timeout ≠ failure. If a wait_* tool returns while the work is still in flight, nothing was cancelled — call it again to keep waiting. This keeps each MCP call comfortably inside client tool-call timeouts.