Failed items need their own retry, not a full redo

What it is

Seventeen succeeded, three failed: the next step is to retry those three, or edit them and retry, not to submit twenty again. Retrying the failed set keeps recovery scoped to the holes. Redoing the batch sends already-successful items through again: duplicate side effects if not idempotent, waste and new partial failures even if it is. This entry is about the scope of the recovery control. It is not about how status is drawn on the list.

Why it happens

After a partial failure the goal is to fill holes, not to redraw the whole picture. If the only button is “try again” and it acts on the original selection, successful items re-enter the pipeline. If the other end does not deduplicate, the holes fill and duplicates appear. Scoping to the still-failed IDs leaves successes untouched. The control has to be nearby: on the failed item, or as “retry N failures,” not back into batch mode to tick from scratch. Redoing the batch also wipes the memory of which rows are already good, and checking cost returns to zero.

Where it stops holding

A transactional batch (all or nothing) has no “already successful” items; there is no object for a scoped retry. Resubmit the whole transaction and say so. If the cause is permission or a rule, the retry button should point at an edit first, not blindly fire the same request. In-progress items are not failures and must not be swept into “retry failed.”

Applying it

• On a mixed result, offer “retry failed items” whose payload contains only still-failed identifiers; do not send successes again.
• Also put retry on the single item, so one row can be handled alone.
• Before retrying a non-idempotent failed item, query that item’s state and drop it from the failed list if it already succeeded.
• Verify after seventeen-and-three: press recover. If the server receives those seventeen IDs again, the control is still redoing the batch.

Related

• Within the group: H3.13.1 Partial batch failure needs per-item status · H3.13.3 Partial success must not be labeled as total failure · H3.13.4 Say whether the failed items already had side effects
• Adjacent: H3.10 Retry strategy · H8.02 Batch operations · H1.07 Preventing duplicate submit
• Search terms: retry failed items · partial failure · idempotency