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.
- Sume image 400s name the valid values: retry in code
Sume's Image API 400 bodies carry details.supported, allowed, min and max. A tested error table and a small function that retries with a valid value.
- Sort Sume image models by created? The field is one shared value
GET /v1/images/models returns the same created timestamp for every model, so it cannot tell you which is newest. What to use instead, with a script to prove it.
- Sume SDK error.retryable: server flag first, status only as fallback
SumeApiError.retryable uses the error envelope's retryable flag when present and falls back to 408, 429 or 5xx otherwise. A 409 is never retried by status.
Written by Sume