A legacy integration timed out. Should you retry?

Treat an unknown result as its own state

Take an illustrative booking example: your application submits a reservation, but the confirmation never arrives. The supplier may have accepted it. Repeating the request could create another booking. Amazon's Builders' Library explains this ambiguity and how idempotent APIs use request identifiers to recognize retries.

For the maintenance team, the first task is to make that uncertainty visible. Distinguish a confirmed rejection from a missing response. Name the person or team responsible for investigating unresolved operations, and give them a queue they can actually work through.

Write a recovery card for one critical operation

Choose an integration whose failure disrupts daily work. Sit with the people who handle its exceptions and write down how they determine what happened. A useful recovery card should let another engineer or operator follow the investigation without relying on the original developer's memory.

• Which application or supplier is authoritative for the result?
• Which reference can locate the intended operation?
• What evidence permits a retry, and when must it wait for investigation?
• Who can correct a duplicate, and how is that correction recorded?

Check the contract before adding retries

If the receiving API supports an idempotency key, verify its scope, retention period and handling of changed parameters. Reuse the identifier for a retry of the same intended operation. A new intended operation needs its own identity.

An integration wrapper alone cannot guarantee that an external legacy system executes once. If the receiver offers neither deduplication nor a reliable status lookup, document the limitation and route uncertain writes for reconciliation instead of silently repeating them. Decide the acceptable recovery procedure with the business owner.

Test the incident, not only the successful call

Use a test environment and synthetic records to rehearse the recovery card before changing production behavior. Ask an engineer who did not write the integration to handle a simulated exception. Record where the instructions, access or evidence are insufficient.

• The receiver accepts the operation, but the caller loses the response.
• An operator and a background job both try to resolve the same pending item.
• An old pending item is encountered after a release or restart.
• The status lookup is unavailable, leaving the outcome unresolved.

Keep the same recovery rules when AI joins the workflow

For an AI-assisted workflow, design the execution service to own operation identity and recovery state. The agent can explain an unresolved item or prepare an investigation summary, but a confident answer is not evidence that the underlying booking exists. Show the supporting record to the operator.

Track unresolved-item age, investigation effort and confirmed duplicates before and after the change. These are practical signals for deciding whether the workflow has improved. Review them alongside normal maintenance and feature work.

This is the kind of focused engineering work that belongs inside a long-term engagement. UVISION provides dedicated developers and managed projects, with at least one full-time developer per project. Understanding how a system fails and recovers supports its continued development, including future AI capabilities.