Failed Sume video job: resubmit or stop? Read retryable, next_action

Resubmit a failed Sume video job only when its error says retryable is true, and wait retry_after_seconds when that field is set; for next_action fix_input, change the request instead, and for add_funds, top up first. The error object on the job, described as PublicDeveloperApiJobError in the OpenAPI document, carries category, stage, retryable, retry_after_seconds, public_reason and next_action for this purpose.

OpenAI's video guide, read 2026-10-08, lists failed as a terminal status; I found no field there that tells you whether to try again.

Fields and the action they imply

Read the error from GET /v1/jobs/{id}/status, under the job object, or from the terminal event in the events timeline.

A decision function

This runs as written; the sample is the example that appears in the OpenAPI document. Replace it with the error you read from a real job.

def decide(error):
    if error is None:
        return "no error on this job"
    action = error["next_action"]
    if error["retryable"] and action == "retry_later":
        wait = error.get("retry_after_seconds") or 60
        return "resubmit with a new key after %d s" % wait
    if action == "add_funds":
        return "top up the balance, then resubmit with a new key"
    if action == "fix_input":
        return "change the request; the same body will fail again"
    return "log the job events and send to a human"

def main():
    sample = {"code": "generation_failed", "message": "Generation failed.",
              "category": "generation_rejected", "stage": "generation_processing",
              "retryable": False, "retry_after_seconds": None,
              "public_reason": "generation_rejected", "next_action": "inspect_events"}
    print(decide(sample))

main()

Why a new key

The docs say the same Idempotency-Key and body replays the first job, so assume a resubmit under the old key hands you the failed job back. Derive the new key from your record id plus an attempt number, and cap attempts at two or three so a persistent failure does not keep reserving credits.

For failures that come back as HTTP errors instead of failed jobs, see the error mapping post; for a prompt the model refused, see the rejection post.