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.

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.
| Category | Typical next action |
|---|---|
validation | Fix input |
auth | Check API key and workspace access |
quota | Add funds or lower request cost |
queue | Retry later with the same idempotency key |
generation_rejected | Inspect events and fix unsupported input |
generation_timeout, worker_timeout | Poll status or retry later |
runtime_unavailable | Retry 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
- Wan 3.0 request returns 409 idempotency_conflict after a prompt edit
Reusing an Idempotency-Key with a changed Wan 3.0 payload returns 409 idempotency_conflict. Use a new key for a new prompt; reuse it only for exact retries.
- Wan 3.0 polling every 15 seconds vs Sume's 30-second poll
Alibaba recommends polling Wan 3.0 every 15 seconds. Sume's video guide uses 30 seconds and a signed callback_url. Which to pick and why.
- Wan 3.0 has six regional endpoints; Sume has one base URL
Alibaba's Wan 3.0 API is served from six regions with a workspace id in the URL. Sume's video API uses api.sume.com/v1/videos with no region field.
- Wan 3.0 video URL purged after 24 hours: what Sume returns
Alibaba keeps Wan 3.0 task ids and video URLs for 24 hours. Sume returns media.sume.com artifacts instead. What to store and when to download.
Written by Sume