Your batch job writes results to the database by position, and some customers now see each other's summaries. What is the bug?
Why B is the answer
Results can arrive in any order, so they must be joined on custom_id
Batch results may not match the order of the requests. custom_id exists so that each result can be matched back to its request.
In detail
- Batch results may not come back in request order.
- Writing by position attaches a result to the wrong record, which here exposes one customer's data to another.
- custom_id exists for matching each result to its request.
- Use a customer or record ID as the custom_id, so the join is direct.
Use case
An illustrative scenario, not a real incident.
A billing tool writes the third result to the third customer. Results returned in a different order, so summaries reached the wrong people. Joining on custom_id fixes it for good.
See it in different ways
flowchart LR A["Requests with custom_id"] --> B["Batch runs, up to 24 hours"] B --> C[".jsonl results in any order"] C --> D["Join on custom_id"]
sequenceDiagram participant J as Your job participant B as Batches API J->>B: Requests, each with a custom_id B-->>J: Results, in any order J->>J: Match each result on custom_id J->>B: Resubmit errored and expired ones
flowchart TD
Q{"How do you match results?"}
Q -->|"By position"| A0["Results can land on the wrong record"]
Q -->|"By custom_id"| A1["Each result finds its record"]Key point: Never join batch results by position.
Why the other options are wrong
- A. The results file was parsed as JSON Lines
- JSON Lines is the format of the results, so parsing it that way is correct.
- C. The results stay locked until the full 29 days of availability have passed
- The 29 days is how long results stay available. Nothing is locked for that time.
- D. The batch expired before it finished
- An expired batch would leave results missing, not swapped.