A batch returns some errored and expired results. How do you recover?
Why C is the answer
Resubmit only those requests, found by custom_id
Errored, canceled and expired requests are not billed, so rerun just those. The 29 days is how long results stay available, not extra processing time.
In detail
- Errored, canceled and expired requests are not billed.
- Find them by custom_id, and resubmit only those.
- Results stay available for 29 days, but that is not extra processing time.
- Check why requests errored first, because resubmitting a bad request fails again.
Use case
An illustrative scenario, not a real incident.
A batch of 10,000 finishes with 40 errored and 12 expired. Rather than rerun everything, the job finds those 52 by custom_id and submits them again.
See it in different ways
stateDiagram-v2 [*] --> Processing Processing --> Ended Ended --> Succeeded: use the result Ended --> Failed: errored or expired Failed --> Processing: resubmit by custom_id Succeeded --> [*]
flowchart TD
Q{"What is the result?"}
Q -->|"Succeeded"| A0["Store it"]
Q -->|"Errored"| A1["Fix if needed, then resubmit"]
Q -->|"Expired"| A2["Resubmit"]Key point: Resubmit only what failed.
Why the other options are wrong
- A. Accept the partial output, because those requests were billed already
- Failed requests are not billed, and leaving them means missing data.
- B. Wait another 29 days, because the unfinished requests may still complete
- Expired requests will not finish later. The 29 days applies to retrieving results.
- D. Rerun the entire batch, because partial results cannot be relied on
- Rerunning everything pays again for results that already succeeded.

