Runway Recipe tasks vs Sume jobs: waiting on the result

Each Runway Recipe call returns a task. Runway's SDK examples wait for the finished output; with cURL you poll GET /v1/tasks/{id} for status and the output URL. Sume has the same shape under a different name: a paid generation returns a job, and you read it at GET /v1/jobs/{id}/status and GET /v1/jobs/{id}/result, or receive a webhook if you passed an HTTPS callback_url.

Runway details are from its recipe pages; Sume details from Video generation and Generation admission, read 2026-10-01.

How do the two lifecycles line up?

Which statuses should I expect?

The video poll response lists pending, in_progress, completed, failed and cancelled. The admission guide describes the lifecycle as queued, processing, then completed, failed or canceled. Either way, only the last three are terminal. Keep polling until the response says terminal: true, or until your own deadline.

Is queued a failure?

No. The docs say not to treat queued as failure: store the job_id, poll with exponential backoff, and fetch the result only when the job reports result_ready: true or status: completed. A job waits as queued when the workspace is at its concurrency limit but still has queue capacity.

What if my worker times out?

Do not resubmit the paid request because your local worker timed out. Re-read the same job id; a retry with the same Idempotency-Key returns the original job. For webhook handling see debug Sume webhook delivery.