A Sume image job at 50 seconds: slow, queued, or stuck?

If an image job is still running after a 50-second jobs_wait, Sume's Jobs and results page says it is usually stuck, not slow. First check whether it is actually processing or only queued behind other work. Then read jobs_events. Do not submit the paid create again: a second submit is a second charge, and the first job keeps running.

Step 1: queued or processing

queued is a normal accepted state. Sume applies concurrency when workers move jobs into processing, not when it accepts them. A Free workspace processes 1 job at a time, so a job submitted behind five others waits its turn, and that wait is not a fault. The 50-second rule applies to a job that is processing.

Step 2: read the facts

Use jobs_status for one immediate read and jobs_events for the public timeline, which exists for debugging and recovery. A failed job carries a public error category such as generation_timeout or worker_timeout, whose documented next action is to poll the status or retry later, and generation_rejected, which means correct the unsupported input. jobs_wait also reports outcome: operator_stopped when Sume operations stopped the job; those jobs are terminal, produce no output, and their holds are refunded.

Step 3: decide

Cancellation succeeds only before generation work starts, so it is useful for a job that is still queued, not for one already rendering. Use these rules:

• Job is queued: keep waiting, or cancel it if you no longer need it. Use jobs_cancel, which needs Write and an idempotency_key.
• Job is processing past a few more slices: keep reading jobs_events and re-issue jobs_wait; transport errors such as 524 are not job outcomes.
• Job is failed: read the error, correct the input if the category says so, and submit a new create with a new idempotency_key.
• Job is completed: read jobs_result and deliver.

What not to do

Do not resubmit only because a local process timed out. If you must retry a create, reuse the same idempotency_key for the exact same payload. Sume answers 409 idempotency_conflict when a key is reused for a different operation or payload. And do not ask jobs_wait for a longer slice: the cap is 55 seconds, and larger values are clamped, as the wait_slice_clamped field will tell you.

A worked example on Free

Suppose an agent on a Free workspace submits eight image jobs in a row. Free accepts 6 in total (1 processing plus 5 queued), so the first six are accepted and the seventh and eighth fail at submit with 429 queue_full. Of the six accepted, five sit as queued while one runs. A jobs_wait on the fifth queued job at 50 seconds is not a stuck job: four other jobs must finish first.

Where Sume returns the generation_limits snapshot, it shows active_generation_jobs and queued_generation_jobs, so the agent can tell the difference without guessing. For the queue_full pair, wait for capacity, then retry with the same idempotency key, as the admission page directs.