Queued Sume job: retry_after_seconds is capped at 30 seconds

A queued Sume job that is not yet due to start can report retry_after_seconds and next_poll_after_seconds above the usual 2, but never above 30. The API caps the public value at 30 seconds, so your poll gap should never be longer than that hint even for a job waiting behind a full workspace.

The cap and the 2-second default come from the job status metadata in the API. Treat the server hint as a floor for your sleep, and your own backoff as the fallback.

When does the hint rise above 2?

In the API code, a non-terminal job has a retry_after_seconds only when its availability time is more than 2 seconds away, and the value is the seconds until then, capped at 30. Otherwise retry_after_seconds is null and next_poll_after_seconds is 2.

This is the retry-style hint of the job record, separate from the HTTP retry-after header on a 429. Per MDN, that header is seconds or a date.

Does a queued job mean something is wrong?

No. The admission docs call queued a normal accepted state: concurrency limits apply when workers move jobs to processing, not when the API accepts them.

Free workspaces process 1 job at a time with 5 queue slots, and Pro processes 4 with 20, by the default table. Always prefer the effective generation_limits on your submit response over the table.

How should a poller use the hint?

Poll no faster than the hint, and not slower than 30 seconds. A tight loop across many jobs is the real risk, since status reads have their own rate-limit budget and can return 429 rate_limited.

curl -s https://api.sume.com/v1/jobs/job_123/status \
  -H "Authorization: Bearer $SUME_API_KEY" \
  | jq '.data // . | {terminal, next_poll_after_seconds, retry_after_seconds}'

What Sume does not do

Sume does not give a per-job queue position or ETA, only the counts in generation_limits and these poll hints. Do not tell users a precise wait time from them.

Quick checklist

The points above reduce to a short list you can paste into a runbook.

• Use next_poll_after_seconds as a floor for your poll gap.
• Never wait longer than 30 seconds because of this hint.
• Treat queued as a normal state, not a failure.
• Back off on 429 rate_limited and honor retry-after when present.
• Prefer generation_limits on your submit response over the static plan table.