Poll Recast like a queue client: IN_QUEUE to COMPLETED

Two vocabularies, one job

Sume's Jobs and results page says the status endpoint returns a queue-shaped status field, IN_QUEUE, IN_PROGRESS, COMPLETED, FAILED or CANCELED, that maps one-to-one onto sume_status, for clients ported from other queue APIs. The two never disagree, but the page says not to mix them in one code path.

That helps if your Recast code started life against fal's queue, where a person-swap job is submitted and polled. fal's page, read 2026-10-03, describes the model and its price, not Sume's statuses.

The mapping

What queued means here

On Sume, queued is a normal accepted state, not a failure. The Generation admission page explains that concurrency is a dispatch limit, not a submit limit: with a limit of one, you can submit several jobs and they run one at a time, as long as balance and queue capacity allow. When the queue is full, new paid submissions fail with 429 queue_full.

Poll on the booleans terminal and result_ready, honor next_poll_after_seconds when present, and read the result only when it is ready. Reading it earlier returns 409 job_not_completed.

A small adapter

Pick one vocabulary and convert at the edge. The code below reads the queue-style field only.

def is_done(status_body):
    s = status_body.get("status")
    if s in ("FAILED", "CANCELED"):
        raise RuntimeError(f"job ended: {s}")
    return s == "COMPLETED"

Why not mix the two

The docs warn against mixing the vocabularies, and the reason is plain: a branch that tests sume_status == "completed" and another that tests status == "COMPLETED" will drift apart the first time someone edits one. Choose the one that matches your existing client and put the conversion in a single function.

Backoff matters more than the label. Use next_poll_after_seconds when the response carries it and exponential backoff otherwise, and set a client-side deadline that suits the clip; a 30-second Recast clip is longer work than a still image.