Sume job failed: generation_output_unavailable, retry or not

generation_output_unavailable means Sume could not copy a generated file into its own storage, so there is no media.sume.com URL to hand you. If retryable is true and next_action is retry_later, wait retry_after_seconds and try again; if retryable is false, next_action is contact_support.

Sume gives out only its own durable media URLs. Jobs and results says to use the Sume media URLs from the result and that raw provider URLs are not public API outputs, which is why a failed copy ends the job instead of leaking the provider link.

What the remap does with a mirror failure

Two stored codes, media_mirror_failed and artifact_mirror_failed, map to the same public answer: category generation_unavailable, stage generation_processing and public_reason: generation_output_unavailable. The retry fields come from the stored flag.

The artifact storage client raises its mirror error as retryable by design. Its message reads "Artifact mirror request failed." when no HTTP status came back, or "Artifact mirror failed with status N." when the storage side answered, and a transient status also asks the job to wait before the next attempt.

What it is not

Three look-alike failures need different handling, so rule them out first.

• Not an input problem. There is no fix_input here, so changing your prompt or picture does nothing.
• Not a size problem. A finished file that the storage refuses as too large fails as artifact_too_large, and that one is never retryable. See the artifact_too_large guide.
• Not an expired link. Result URLs are Sume media URLs, and a copy that never happened simply has no URL.

What a video client sees

On the video endpoint, the poll at GET /v1/videos/{id} reports status: failed and a plain-string error. A download from GET /v1/videos/{id}/content on a failed job answers 409 job_failed with retryable: false and next_action: inspect_events, which is the signal to read the job rather than to retry the download.

A safe order of operations

Because a retry can cost another generation, check before you resubmit.

The wider table of which categories deserve a retry is in ten job error categories.

• Read GET /v1/jobs/{id} and confirm public_reason is generation_output_unavailable.
• Read GET /v1/jobs/{id}/events for the timeline of the attempt.
• If retryable is true, wait the stated retry_after_seconds, then submit again with a fresh Idempotency-Key, because the failed job is terminal.
• If retryable is false, stop and contact support with the job id and the request id from the response headers.