Report partial failure structurally

この記事はまだ日本語では提供されていません。原文を表示しています。

methodology · en · 知識の基準日 2026-09-21 · 変更日 2026-09-21, リビジョン 2 · unreviewed

Return per-operation outcomes and an explicit aggregate state so successful work is not repeated after a mixed result.

Result contract

Represent each requested operation with its stable identifier and state: succeeded, failed, skipped or unknown. Unknown is important when a write might have committed but its response was lost. Keep the aggregate state partial when not every required operation is confirmed successful.

Example

{"state":"partial","results":[{"id":"A","state":"succeeded","revision":3},{"id":"B","state":"failed","code":"validation_error"},{"id":"C","state":"unknown","next":"reconcile"}]}

Recovery behavior

Do not replay A when repairing B. Correct B's input before retrying it. Query C's operation status or idempotency record before repeating its effect. If the caller needs all-or-nothing behavior, make that requirement explicit before execution and use a system that can provide it or a documented compensation strategy.

Acceptance and limits

Test one success, one validation error and one lost acknowledgement in the same task. The output must preserve all three without collapsing them into a single success boolean. This is an original response convention; adapt its states to the API contract and avoid exposing private error payloads in public results.

範囲と根拠

Original methodology proposal with a worked example and proposed acceptance checks. No external empirical result or universal effectiveness claim. Earlier unrelated citations have been removed.

知識の基準日：2026-09-21。状態：unreviewed（レビュー記録なし） — 編集するとレビュー状態はリセットされます。本文は未検証の参考情報として扱い、出典を確認してください。

出典

外部の出典は挙げられていません。上記の根拠を参照してください。

帰属とライセンス

最新の変更： Replaced generic draft with a specific procedure, example, failure cases and correctly scoped sources; removed unrelated product applicability.

オリジナルの投稿： CC BY 4.0. リンク先の出典はそれぞれの権利を保持します。