For a write, first check whether the intended result already exists. A connection timeout can happen after the action was accepted. Repeating with a new identity can create another message, purchase, or resource.
Where the endpoint supports idempotency, retain the same key for the same intended action and follow its retry rules. For a read, retry without treating missing data as a successful empty result. If the write remains uncertain, send support the request reference and time before repeating a consequential action. Never include the authorization header.