Several operations in a parallel batch can fail while others are still running. How would you design exception, cancellation, and partial-result behavior?

Handle exceptions, cancellation, and partial results in parallel work

Defines what happens when several operations fail, cancellation arrives, or only part of a parallel batch completes, without orphaning work or hiding errors.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would keep ownership of every started operation and await the whole group so exceptions are observed. Cancellation should be passed to each operation and checked cooperatively, while the coordinator stops scheduling new work when cancellation or a fail-fast policy applies. I would decide whether the batch is all-or-nothing, best-effort, or itemized partial success before choosing the return type. A canceled or incomplete batch must not be reported as successful merely because some items finished.

Full answer below

Practice focus

Multiple failures, cooperative cancellation, task observation, partial completion, idempotency, selective retry, structured ownership, and truthful batch status.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Parallel work creates multiple outcomes, not one linear try/catch path. The caller needs an explicit contract for first failure, remaining work, partial success, retry, and cancellation.
I would keep ownership of every started operation and await the whole group so exceptions are observed. Cancellation should be passed to each operation and checked cooperatively, while the coordinator stops scheduling new work when cancellation or a fail-fast policy applies. I would decide whether the batch is all-or-nothing, best-effort, or itemized partial success before choosing the return type. A canceled or incomplete batch must not be reported as successful merely because some items finished.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
With Task.WhenAll, several tasks may fault even though awaiting the combined task rethrows one exception directly, so I would inspect the completed tasks or the combined task's exception data when every failure matters. Parallel loop APIs can surface aggregated failures and may already have started multiple iterations before one fails. For itemized processing I would record each item as succeeded, failed, or canceled with a stable idempotency key, then retry only failures that are safe to repeat. If one failure invalidates all output, I would stage results and publish them only after the full batch succeeds.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Returning after the first exception while other started tasks continue unobserved.
Treating cancellation as an error in one place and success in another.
Retrying the whole batch when completed items are not idempotent.
Returning a result collection without indicating that it is partial.

Several operations in a parallel batch can fail while others are still running. How would you design exception, cancellation, and partial-result behavior?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Try a variant

Technologies

Tech stacks

Skill areas

Suggest an improvement