Sume job failed artifact_too_large: shrink the output, don't rerun

A Sume job failing with artifact_too_large or artifact_upload_rejected made its file but could not store it. Make the file smaller; rerunning changes nothing.

4 min readSume
All posts

When a Sume job fails with public_reason artifact_too_large or artifact_upload_rejected, generation itself ran: the finished file was refused by artifact storage. It is not a timeout and not a capacity problem. The envelope is category: generation_rejected, stage: generation_processing, retryable: false, next_action: fix_input, so the fix is a smaller output, such as a shorter cut or lower resolution, not a rerun.

How are the two reasons chosen?

The job mapper reads the storage response status recorded on the job as artifact_upload_status. A 413 becomes artifact_too_large. Any other 4xx becomes artifact_upload_rejected, except 408 and 429, which are the transient statuses and stay out of this rule. Anything outside the 4xx range is not mapped here.

The messages differ accordingly. For 413: the generated file was larger than the artifact upload limit, so produce a smaller file, with a shorter cut, a lower resolution or a lower bitrate. For the other statuses: artifact storage rejected the generated file. Both end by saying that re-running this request unchanged will fail the same way. The public docs do not publish a numeric limit, so do not hard-code one.

What should I change first?

Change whichever input drives file size. For a Timeline render that means fewer or shorter segments, or a lower output resolution; for model output it means a shorter duration or lower resolution where the model's schema offers one. Then submit as a new request with a new Idempotency-Key; the same key replays the stored failure instead of trying again.

Artifact storage failures versus look-alikes, from the Sume public job mapper, read 2026-10-11.
Signalpublic_reasonRetry the same request?
Storage status 413artifact_too_largeNo
Storage status 4xx except 408, 429artifact_upload_rejectedNo
Storage status 408 or 429not mapped hereFollow the job's retryable
Generation timeoutsee job stage and retryableFollow the job's retryable

How do I tell it apart in code?

Branch on public_reason, then on the flag. This keeps a retry loop from burning attempts on a file that will be refused again.

def next_step(job: dict) -> str:
    err = job.get("error") or {}
    reason = err.get("public_reason")
    if reason in ("artifact_too_large", "artifact_upload_rejected"):
        return "shrink output (shorter, lower resolution or bitrate); new Idempotency-Key"
    if err.get("retryable"):
        return f"retry after {err.get('retry_after_seconds') or 30}s with the same key"
    return f"do not retry; next_action={err.get('next_action', 'unknown')}"


print(next_step({"error": {"public_reason": "artifact_too_large", "retryable": False}}))

Sources

Related posts

More in Developers

All Developers posts

Written by Sume