When a bulk operation partly fails, whatever already succeeded should stay done

What it is

When an operation bundles several subtasks — deleting fifty files at once, notifying a hundred people, importing a spreadsheet with many rows — and a handful of those subtasks fail, the system should keep whatever succeeded and report only the failures separately, instead of treating the whole operation as one failure and asking the user to start over from scratch. This sounds like a small detail, but it decides whether the cost of a partial hiccup is "redo the three failed records" or "redo all one hundred," and the gap between those can be tens of times over.

Why it happens

Treating "partial failure" as "total failure" usually comes from borrowing the database-transaction idea of all-or-nothing commitment — a correct principle for guaranteeing underlying data consistency, but one that creates needless waste when applied directly to a multi-step, user-facing operation: the user isn't looking at a single record that has to stay internally consistent, but a batch of subtasks that are genuinely independent of one another, where success or failure of one has no bearing on the rest. Three failed import rows don't require voiding the other ninety-seven. Preserving completed work requires the system to record each subtask's outcome individually as it executes, rather than waiting until everything finishes to decide success or failure as a single verdict — only then can it precisely re-run just the failed portion when a partial failure occurs.

Where it stops holding

This principle applies to batch operations whose subtasks are genuinely independent of each other. If the subtasks have a real dependency, or the whole batch has to stay consistent as a unit — a transfer's debit and credit legs must succeed or fail together — forcing preservation of partial results would corrupt correctness, and this scenario still needs the all-or-nothing semantics that a real transaction guarantees; the principle doesn't apply there. The deciding factor is whether the subtasks are genuinely coupled, not whether the operation looks like "a batch" in the interface.

Applying it

For any interface that lets a user submit multiple subtasks at once, report the succeeded and failed subtasks as separate lists after execution, give a specific reason for each failure (insufficient permission, bad format, target no longer exists), and offer a retry entry point only for the failed items — don't ask the user to re-select or re-enter the parts that already succeeded. If the subtasks genuinely have a real dependency, tell the user explicitly that this operation is all-or-nothing, rather than presenting two entirely different failure semantics through the same interface language. Verification: in a test environment, force a fraction of subtasks in a batch operation to fail, then measure how many steps the user needs to fix the remainder. If that step count is comparable to redoing the whole batch from zero, the partial results weren't actually preserved — they were just re-exposed to the user in a different form.

Related

• Same group: A10.08.1 fault tolerance — the system stays recoverable after an error occurs · A10.08.5 degradation order is predefined, not decided at runtime · A10.08.6 a checklist for identifying irreversible actions
• Nearby: A10.03 omission errors and execution errors
• Search terms: partial failure · batch operation · graceful error handling