Did the process fail, or did you just lose the response?
A connection drops just after an application receives a request. Your process shows an error, but that does not prove the operation never happened. Sending it again without checking can leave you with two records, two bookings or two notifications. The useful question is what happened in the destination system.
A response error does not explain the outcome
Separate three situations: a request rejected before work starts, a confirmed operation and an unknown outcome. That last state needs a check, not a blind automatic retry. Keep the request identifier and look for the result in the service responsible for storing it.
In an administrative workflow, for example, failing to receive confirmation is not enough reason to create another record. First check whether the original exists. This is a design example, not a guarantee about every application.
One operation needs one identity
Some APIs support idempotency keys: identifiers that let a service recognise a retry of the same operation. Stripe documents this mechanism to avoid creating an operation twice. The exact behaviour depends on the service, its version and how long it retains the key.
Do not generate a new key for every attempt if the destination needs to recognise them as the same operation. Do not reuse a key for different operations either. Keep personal data out of keys. If a service does not offer this mechanism, design duplicate checks and a review step for uncertain outcomes; a preliminary search alone does not eliminate every race between simultaneous processes.
Test the interruption, not only the happy path
In a test environment, check what happens when the response disappears after the result is saved. Also check simultaneous requests, changed inputs and a retry outside the period supported by the service. Do not run these tests with real charges or real communications.
Keep a record linking the operation, its attempts and the final outcome, using only the data needed. Define when the process stops to resolve the uncertain outcome. A retry is useful when it recovers an operation; it stops being useful when it quietly creates a second one.