Sume bulk items ignore on_active_run skip: allow is forced
Setting on_active_run skip or reject on a Sume bulk item does not stall the window, because the bulk controller runs every item with allow. What that changes.

What happens if a bulk item says on_active_run: "skip"? Nothing special. The Bulk runs docs say the bulk controller owns single-flight and executes every item with on_active_run: "allow", so sending skip or reject on an item does not stall the window on the first in-flight run of that Format. A single run is different: there skip records a terminal skipped run when another run is in flight, and reject answers 409.
The practical effect is that a script ported from single-run calls keeps working in a queue, but its de-duplication guard does not.
What still protects you from duplicates
Use the Idempotency-Key. A replay of the same key and payload returns 202 and the existing queue, and the same key with a different payload is 409 idempotency_conflict with details.queue_id. Mint a fresh key per batch; reusing last week's key with this week's list is the usual cause of the 409.
Inside one queue, de-duplicate rows yourself before you build items, since the queue will happily run two identical items.
What to use instead of skip
If you wanted skip to stop duplicate work, replace it with two guards you control. First, an idempotency key per business intent, so the same job sent twice is one queue. Second, a row table on your side that records which rows have a run in flight, so you do not put them in a second queue.
If you want to stop work already queued, cancel the child runs individually. The docs say canceling a child marks the item canceled and frees its slot for the next queued item, and that there is no cancel-queue endpoint.
None of this matters for single runs, where skip and reject behave as the Runs docs describe.
Single run versus bulk item
| Setting | Single run | Bulk item |
|---|---|---|
| allow | Starts a run | Starts a run |
| skip | Terminal skipped run, no work, no webhook | Treated as allow; window is not stalled |
| reject | 409 when a run is in flight | Treated as allow |
| Queue item table | Not applicable | A skipped child is recorded as failed |
De-duplicate before you submit
This snippet removes repeated rows by a stable key before building the queue body, keeping the first occurrence and the original order.
rows = [
{"sku": "mug-01", "offer": "20%"},
{"sku": "mug-02", "offer": "20%"},
{"sku": "mug-01", "offer": "20%"},
]
seen, items = set(), []
for r in rows:
k = (r["sku"], r["offer"])
if k in seen:
continue
seen.add(k)
items.append({"instruction": f"Spot for {r['sku']}", "input": r})
body = {"concurrency": 4, "items": items}
assert len(body["items"]) == 2
print(len(body["items"]), "items")Sources
Related posts
More in Developers
- Count Sume bulk webhooks to know the queue is done, and the trap
A Sume bulk queue has no webhook, so some teams count per-item deliveries. Canceled and skipped runs never deliver, so a pure counter can hang. Use a hybrid.
- Run sume doctor --agent --json as a CI preflight and keep the output
sume doctor --agent --json checks local CLI readiness without calling the API. Run it before job steps, fail on bad JSON or a nonzero exit, and keep the file.
- Sume Format run status is spelled canceled with one L: fix your switch
A Format run ends as completed, failed, canceled or skipped. If your code matches cancelled with two Ls, a canceled run will look like it never ended.
- Sume Free plan and Omni: one running, five queued, seventh gets 429
On a Sume Free workspace one video job runs and five wait; a seventh submit returns 429 queue_full. What that means for an Omni test batch and its cost.
Written by Sume