Bulk run item completed is not success: check before you publish

In a Sume Format bulk run, a child with status completed has not necessarily succeeded, so check each child's result before you publish. There is no queue-level webhook; set communication.webhook_url on each child.

What the docs say

From the bulk-runs docs, as of 2026-10-08.

• Queue size: 1 to 100 items; concurrency 1 to 16.
• Replayed Idempotency-Key returns 202 with the old queue.
• Same key with a different payload returns 409.
• generation_spend_cap_usd is per item.

A pre-publish check

For a 100-item holiday queue, count the children and compare against the successes you expect.

Failure handling

Collect the failed items into a new queue with a fresh Idempotency-Key. Because the cap is per item, the retry queue has its own ceiling. Do this before the sale starts, since an item that failed quietly leaves a hole in the catalog.

Per-child webhooks

Because there is no queue-level webhook, set communication.webhook_url on every child. A receiver must refuse an empty signing secret and should treat the webhook as a hint to read the job, not as proof of success. At concurrency 16, expect bursts of up to 16 events close together, so acknowledge fast and process on your side.

Log the child id with its SKU; the log is what lets you list the SKUs that have no usable output.

• Acknowledge first, process later.
• Read the job result after the webhook.
• Never mark a SKU live from a completed status alone.

Before you scale

The cost of an unnoticed failure is a gap in the sale, not just a wasted clip. A queue summary that says all 100 children completed may still hide a handful with no usable output. Make the publish step read the result of each child and refuse to continue on any child whose output is missing, and print the list of those SKUs for a human to review.