Explain a Partly Successful Batch Before Repeating It

After a batch partly succeeds, report each item's outcome and the evidence for its effect before offering another action. Succeeded, skipped, failed, and unknown items need different next steps. Repeating the original selection can overwrite later work or repeat an effect that already happened.

A batch-level response cannot answer all of those questions. Microsoft Graph's JSON batching documentation provides one concrete protocol example: an outer 200 response does not mean its individual requests succeeded. That provider-specific distinction motivates inspecting item results; it does not define the recovery policy for every application.

The example below is a fictional five-note list operation, not a Graph request or recorded response. All receipts and outcomes are authored teaching data. No notes were changed and no API was called.

Name the batch and the intended item effects

The requested operation is to set five selected notes' labels to Ready. The fictional batch is B7. Every item also has its own request identity, so an item result can be associated with the intended attempt rather than whichever row happens to occupy a position in the display.

Assume the hypothetical outer response is 200: the application received an envelope. Separate that transport fact from the item ledger:

The request identities and receipt terms belong to this fictional contract. They do not imply that a particular SDK exposes an operation-status endpoint or uses these fields.

N13 is skipped for an explicit reason. It is not a third newly successful update. N14's failed outcome includes evidence that this attempt did not mutate the item. That no-effect conclusion cannot be generalized to every error from another service. N15's last known Draft label is not its confirmed current label.

Make the summary add up without hiding uncertainty

For these five items, show:

2 succeeded · 1 skipped · 1 failed · 1 unknown

The four counts sum to five. There are two confirmed applied effects, two confirmed no-write outcomes, and one unresolved effect. Do not put the unknown item into the failed count merely to make the result look finished.

The interface should keep access to the per-item explanation. A summary reading “completed with errors” does not tell someone whether to repair an input, leave a successful item alone, or investigate a missing receipt.

Divide the next work into different sets

The initial recovery plan is:

N14 is a correction candidate because the fictional receipt says O14 ended without mutation. It still needs a current check of the category, permission, item state, and intended new input. The old failure is neither permission to change the item now nor proof that the same rejected input will work later.

For N15, checking only whether the label now reads Ready may not identify what happened to O15. Another action could have produced the same label. Use whatever authoritative item/attempt evidence the selected application actually provides. If it cannot establish the relationship, preserve the unknown outcome instead of creating another attempt by guesswork.

Reconcile the unknown item without rewriting history

Here are three alternative follow-ups to the initial ledger, not three steps in one run:

Retain the initial missing-receipt entry alongside the later evidence. The later update should explain how the classification changed, not make it appear that the application knew the result from the beginning.

This table chooses no universal reconciliation API. It states the evidence the reader needs before another action. A builder must identify whether the actual service can provide that evidence, and define a conservative path when it cannot.

Recheck the correction against current inputs and permission

Suppose someone supplies the missing category for N14. The proposed recovery now contains changed input. It is a corrected, reviewed attempt, not a blind repeat of rejected O14.

The last row prevents an old batch instruction from resetting later progress. Even though assigning the same label might appear harmless, the current item may no longer represent the same decision. The recovery view should show the current target and proposed change, not only the old error.

If the corrected attempt is eventually made, record its result under its own reviewed input and identity, with a reference to the failed O14 it addresses. Do not turn the old rejected attempt into a success record.

Explain the repeat risk in concrete terms

Repeating B7 would include N11 and N12 even though their effects were confirmed, include N13 despite its intentional skip, and include N15 while its effect remains unresolved. It would also reuse N14's invalid input unless the request were changed.

The problem is broader than whether writing Ready twice happens to produce the same visible label in a tiny example. The real implementation may contain later edits or additional effects. This guide neither claims those effects exist nor assumes that repeated writes are harmless. It requires the builder to establish the operation's actual semantics before offering a repeat.

Nor does partial recovery mean rolling back the two successes. Reversal would be a separate decision with its own applicable state and history. The chosen policy here leaves confirmed results alone and addresses only supported next actions.

Copy this partial-success brief

Plan a recovery view for fictional batch B7, which sets note labels to Ready.
Use local fixtures only. No live requests or automatic item mutations.

Initial ledger:
N11/O11: succeeded; applied receipt; label changed to Ready.
N12/O12: succeeded; applied receipt; label changed to Ready.
N13/O13: skipped; already Ready; explicit no-new-write receipt.
N14/O14: failed; category missing; terminal rejection before mutation.
N15/O15: unknown; item receipt missing; last known Draft is not current proof.
The authored outer response is 200 and does not replace these item outcomes.

Initial summary:
2 succeeded, 1 skipped, 1 failed, 1 unknown. Total 5.
Leave N11/N12/N13 alone. Review N14 for correction. Reconcile O15.
The immediate replay set is empty. Do not offer Repeat all as the default.

Unknown-item cases:
If exact O15 is confirmed applied: counts 3/1/1/0, no repeat of N15.
If exact O15 is confirmed terminal and not applied: counts 2/1/2/0,
review N15 for a possible new attempt; do not automatically dispatch it.
If unresolved: retain 2/1/1/1. State unknown and report the evidence gap.
Preserve the original missing-receipt history with any later resolution.

Correction cases:
N14 becomes a corrected-attempt candidate only when category is supplied,
current permission allows, current label/intent still fit, and the person
confirms the new input. Changed input gets a new reviewed attempt.
Permission revoked: no candidate. Label now Approved or input changed
again: return to review, do not apply the stale Ready instruction.

Inspect the current batch envelope, item-result correlation, authoritative
effect/status evidence, and correction input/permission checks. Cite files.
Separate failure-with-confirmed-no-effect from errors without such evidence.

Return the item ledger, exact counts, review/reconciliation/action subsets,
and bounded implementation plan. Use the attached cases as expectations;
record separately any checks actually run. Identify evidence the actual
service cannot provide. Do not claim batch atomicity or exactly-once effects.
No real API, SDK setup, account access, dependency installation, production
edits, automatic retries, rollback, publication or deployment in this step.

An offline Python 3.12.14 model checked the authored ledger counts, the three alternative reconciliation summaries, and the proposed work sets. It did not execute any label changes, query operation status, or establish the behavior of Graph or another service. The application-specific evidence remains the deciding factor for a real recovery action.