WaveSpeed task statuses (timeout, deleted) vs Sume job statuses

WaveSpeedAI lists task statuses created, processing, completed, failed, cancelled, timeout and deleted; Sume has queued, processing, completed, failed and canceled. WaveSpeed's timeout and deleted have no Sume status, and Sume reports a timeout as a failed job with a generation_timeout or worker_timeout error category.

WaveSpeed's list is from its REST API docs, summarized by a page fetch on 2026-10-02, which said statuses include these values. Sume's are in Jobs and results and Errors and rate limits.

What are WaveSpeed's task statuses?

WaveSpeed's flow is submit a task with a POST to a model-specific endpoint, receive a task id, then poll for the result. Terminal states stop the loop: completed is success, and failed and the other terminal states mean stop. The base URL on the page is https://api.wavespeed.ai/api/v3 and auth is a Bearer key.

Two of the seven values are worth noticing: timeout, a distinct outcome, and deleted, which suggests a task can disappear after the fact.

How do they map to Sume?

Sume folds failure modes into one failed status and puts the reason in public error metadata.

What should your handler do with a timeout?

Sume's guidance for generation_timeout and worker_timeout is to poll status or retry later. Check retryability and retry-after seconds in the error metadata before resubmitting, and keep the same Idempotency-Key so a retry does not create a second paid job.

Do not treat a client-side network timeout as a failed job. The docs are explicit that a job keeps running and billing after your client gives up watching.

What about deleted tasks?

Sume's docs do not describe a deleted job state, so a port should not wait for one. Store the job id and the result URL when you see completed. Resource objects, such as library assets, have their own vocabulary: processing, ready, failed, canceled and archived, which is a different object from a job. See the managed media API comparison for the wider mapping.