Sume bulk item format_run_failed_to_start: run_id null, queue goes on

When one item in a Sume bulk run cannot start, that item reports the error format_run_failed_to_start with a run_id of null, and the rest of the queue carries on. So a queue can finish with status completed and still have items that never ran. Read counts.failed and each item's error before you call the job done.

What are the three item errors?

The bulk run reference lists them. Only one has no run.

Why does completed not mean success?

Queue status is queued, running or completed. Completed only says every item is terminal. The counts tell you how many failed or were canceled. A job runner that stops at status completed will miss all three error types.

A bad item caught at create is different: the whole call returns 400 invalid_request with details.index pointing at the item, and no queue exists. So failed_to_start is about a failure after the queue exists.

How do I retry only the items that failed?

Collect the indexes whose error is set, rebuild a new bulk request from only those inputs, and send it with a new Idempotency-Key. Reusing the old key with a different payload gets a 409 idempotency_conflict with details.queue_id, and reusing it with the same payload just returns the old queue.

Keep keys scoped to the business intent plus a revision suffix. Keys are scoped to one Format.

• Every bulk item runs with on_active_run allow. A skip or reject set on an item is ignored.
• The queue has no webhook. Set webhook_url per item if you want pushes, and note that canceled or skipped runs deliver none.
• There is no cancel-queue endpoint, so cancel children one by one.

How does this compare with Claude batches?

Claude's batch results come back per request as succeeded, errored, canceled or expired, and only succeeded requests are billed, per the batch page. Sume bills what a started run generated, so read the receipt of each child. See the bulk runs reference.