A lost response does not always mean a failed operation. Your server may have saved a change just before the connection closed. Sending the same request again can be harmless, rejected, or repeated, depending on the endpoint.
Do not give every request the same automatic retry policy.
Classify the operation
A catalog read is usually different from creating a resource or sending an email. Follow the documented HTTP method and endpoint behavior. A method name by itself is not a substitute for reading how the API handles duplicate requests.
Where the provider supports an idempotency key, use it exactly as documented. Keep the same key when retrying the same logical action. Generating a new key for each network attempt defeats its purpose.
If no such mechanism exists, consider checking the current state before repeating a write. A follow button that sets a desired relationship may have a different recovery path from a job that creates a new resource.
Keep retries bounded and add space between attempts. Distinguish temporary transport failures from authentication or validation errors that a delay will not fix.
Test the unknown-result case
Build a fixture that accepts a write and then closes the connection before returning its response. Ask what your app can safely conclude. The interface should not claim either permanent failure or success without the confirmation your design requires.
Then run the recovery path twice. Check for duplicated records, repeated notifications, and unexpected quota use.
An “outcome unknown” state can be an honest part of a reliable system. A controlled reconciliation step is better than a blind loop that repeatedly performs an operation the user intended only once.