Editorial draft available to read. Factual and language review is pending. Examples are illustrative.
Decision and method
Classify failures by the action that can resolve them. A transient interruption may permit retry; rejected data may need correction; insufficient permission requires reviewing access. Use documented service codes and context, and preserve an unknown state when evidence is insufficient for a safe classification of what actually happened remotely.
Illustrative example
Illustrative example: three orders fail because of disconnection, a nonexistent product code and a revoked credential. Only the first enters a bounded retry sequence. The second goes to the catalogue owner and the third to the access owner. Repeating all three every minute would obscure causes without resolving the underlying problems.
Acceptance check
Build a case table containing expected handling, owner and next action. Check that persistent failures leave the retry loop and correcting data allows safe resumption without duplicates. Accept when an operator understands the cause and can distinguish a resolved failure from a message that has merely been dismissed from the dashboard.
Key takeaways
- Retry only when repeating the operation can address the identified cause of failure.