What a retry can break

A timeout means the caller did not receive an answer. It does not establish whether the remote action happened. This matters when a job charges an account, sends an email, or creates a record. Repeating the action can produce a second result.

Give each intended action an identifier before the first attempt. Reuse that identifier on subsequent attempts when the remote system supports idempotency. If it does not, store a local action record and reconcile uncertain outcomes before retrying.

Classify failures. A brief connection failure can justify a delayed retry. A rejected credential needs repair. A validation error needs different input. Sending the same invalid request repeatedly consumes capacity without improving the outcome.

Test the awkward case: the remote service completes the action but the caller loses the response. Check that recovery produces one completed action and a useful audit trail. A successful happy-path demo does not exercise this failure.