Bulk run concurrency 3 with 8 items: what the 202 receipt shows

With concurrency 3 and 8 items, the Sume 202 shows three running and five queued. Item 3 starts when item 0 finishes. Here is how the window and counts behave.

4 min readSume
All posts

With concurrency: 3 and 8 items, the 202 receipt shows three items running and five queued, and counts.total is 8. When item 0 completes, item 3 starts at once, so the window stays at three until fewer than three items remain. This is a server-side queue, not client fan-out.

What the receipt fields mean

Create fills the window already. counts has total, queued, running, completed, failed and canceled, and items holds one row per item in submitted order with index, status, run_id and error. A queued item has run_id: null.

Queue receipt after create, concurrency 3 and 8 items (read 2026-10-06)
FieldValue
statusrunning
counts.total8
counts.running3
counts.queued5
items[0..2].run_idarun_ ids
items[3..7].run_idnull

What can make the window smaller than you asked

completed, failed and canceled children are terminal and free a slot. Children still pass ordinary Format-run admission: wallet, workspace generation concurrency and spend caps. If a child fails to start, that item is failed and the window refills from the queued items.

  • Concurrency is capped at 16, and your workspace's generation concurrency can hold fewer runs in flight.
  • A child that the API claimed but has no run_id yet still counts as running.
  • The docs say the window never goes above concurrency, even if a poll fires more than once.

Polling the same queue

Poll GET /v1/format-run-queues/{id} and watch counts. In a healthy run, running stays at three while queued falls by one each time an item reaches a terminal state, and completed plus failed plus canceled rises to eight.

When all eight are terminal the queue status is completed and finished_at is set. Then read counts.failed, and fetch each child's receipt from its run_id for the media.

Poll the queue status URL rather than guessing from the create response. The counts and per-item statuses there are what tell you how far the batch has drained, and an item's run_id lets you cancel or read a single child.

Treat the concurrency setting as a pacing choice, not a speed guarantee. Test it on a small queue first, then raise it when you are satisfied with how your own downstream steps cope.

Tradeoff

A higher concurrency finishes sooner but spends faster and presses on your receiver and wallet. For a first batch, pick a small window, watch counts, and raise it once a pilot of three rows behaves.

Sources

Related posts

More in Formats

All Formats posts

Written by Sume