Wan 3.0 job failed: read the error category, then pick the next action

When a wan-3.0 job fails, Sume exposes a category, retryability and next action. Which categories to fix, retry or escalate, with the 409 and 429 codes.

4 min readSume
All posts

When a wan-3.0 job fails, read the public error on the job record: Sume gives a category, stage, retryability, retry-after seconds, public reason and next action. validation and generation_rejected mean fix the input; queue, generation_unavailable and runtime_unavailable mean retry later; quota means add funds or lower the request cost. Never resubmit a paid request without the same Idempotency-Key.

Categories and codes come from Sume's Errors and rate limits docs and Jobs and results docs, read 2026-10-02.

Where do I read the failure?

Use GET /v1/jobs/{id} for the job record, because GET /v1/jobs/{id}/result answers 409 job_not_completed for anything that did not complete. Then read GET /v1/jobs/{id}/events for the timeline. Public events do not expose raw provider task ids or URLs.

Include the request_id when you contact support; it is safe to share, unlike keys or signed URLs.

Job error categories and typical next actions from Sume's Errors docs, read 2026-10-02.
CategoryTypical next action
validationFix input
authCheck API key and workspace access
quotaAdd funds or lower request cost
queueRetry later with the same idempotency key
generation_rejectedInspect events and fix unsupported input
generation_timeout, worker_timeoutPoll status or retry later
runtime_unavailableRetry later; do not retry aggressively

Which Wan 3.0 inputs trigger a rejection?

Send what the catalog says: wan-3.0 accepts 2-30 s and 480p, 720p or 1080p. The Video generation docs say provider.options entries are rejected rather than silently dropped, and model_params is an empty allowlist in v1.

Fix the request, then retry with a new key, because reusing a key with a changed payload gives 409 idempotency_conflict.

Do I pay for a failed Wan clip?

Failed jobs and failed queue admission release or refund the reservation where applicable, per the Generation admission docs. A job that completes is captured. If a failed job shows a charge you did not expect, send its request_id and job id to support rather than re-running it.

A 429 rate_limited is a request-volume limit, not a generation failure: back off using retry-after. A 429 queue_full means capacity is used up; see how many Wan clips run at once.

Log the category with every failed job id. A pattern of validation means your request builder is wrong, a pattern of queue means you are submitting faster than your plan allows, and a one-off generation_unavailable usually just needs a later retry.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume