Ivan Matiushkin
API retries and duplicate records: what to check before retrying
An order update times out. Retrying may recover the flow—or create a second order if the destination already accepted the first request. The first task is to establish what happened, not simply increase the retry count.
Independent working demonstration using synthetic data. Not a client deployment.
A timeout leaves an unanswered question
The caller did not receive a usable response. That alone does not show whether the destination committed the record. Keep the source identifier, request identity, payload fingerprint and attempt history. If the outcome cannot be established, keep it unresolved and route it for investigation.
Separate a repeated request from a changed request
A repeat of the same operation should preserve its request identity. The same identity with a different payload needs an explicit conflict policy. A retry mechanism is incomplete if it checks only the HTTP status and cannot tell these situations apart. The destination API determines which guarantees are actually available.
Check the existing synthetic API test pack
Open API Tests and run the pack. IDM-007 checks that the synthetic duplicate response returns HTTP 200 with idempotentReplay=true. RTY-012 injects a 504 response followed by 201 and remains WARNING. These are controlled endpoint checks, not proof of a real vendor’s delivery guarantees. The displayed fixture durations are illustrative, not performance measurements.
Inspect a stronger recovery example
Migration Showcase preserves accepted target records while replaying only failed records. Remove SKU-X99: TX-104 and TX-106 remain exceptions. Restore it and replay: only those two are written. A further replay writes nothing. This demonstrates selective recovery in a controlled target, not distributed exactly-once delivery.
Agree what counts as acceptance
For a real API flow, test an identical repeat, the same key with changed contents, timeout before acceptance, timeout after acceptance and recovery after restart. The last three require a representative test environment and evidence from the destination. Record source/target IDs, attempts and the observed final state. Do not infer a successful write from a retry counter.
A small first assignment
Start with one API operation, its documentation and sanitised failed request/response examples. The deliverable can be a reproducible test pack, a list of confirmed failure modes and proposed recovery rules. Implementation and production rollout are separately scoped after the actual API constraints are understood.