Engineering & performance / DIJION
Make Retry avoid performing the same operation twice
A mobile API guide distinguishing timeout from confirmed failure, with operation identities, server contracts and waiting policies.
Someone taps Save, receives no response and retries. If the server completed the first attempt, two records may be created. Briefly disabling the button does not address another device or network-level repetition. In an illustrative task app, retry behavior is a shared client–server operation contract, not just a user-interface precaution.
A missing response does not reveal the outcome
A timeout does not establish that a request was never applied. RFC 9110 restricts automatic retry of non-idempotent operations unless their semantics are known to permit it or the original was not applied. Similarly, distinguish Failed to save from Unable to confirm the result. Communicate the outcome known, not an assumed failure.
Safe repetition needs server support
Scroll the table horizontally to see all columns.
| Condition | Information needed | Action |
|---|---|---|
| Response lost | Status for the operation identifier | Query the result |
| Same intention repeated | Same scope and payload | Return the contractually defined result |
| User requests a new record | New operation intention | Create a new identifier |
Define identity scope and lifetime
Reusing one key for every save can suppress genuinely new work, while generating a new key for every attempt cannot recognize repeated intention. Specify account scope, operation type, payload matching and retention. Sending a key from the client is not sufficient protection when the server does not actually enforce the agreed contract.
Bound retries and make them stoppable
Immediate endless retries can increase load and uncertainty. Define waiting, attempt limits and cancellation according to the failure type. Authentication failures and temporary service problems need different recovery. On reopening, read the pending operation’s actual status; restarting its visual progress must not automatically submit a second operation.
Duplicate-operation checks
- Complete the server operation but suppress its response.
- Retry with the same identifier and payload.
- Exercise a changed payload with the same identifier.
- Restart the app and reconcile the pending operation.
Acceptance concerns how many times one user intention can be applied, not merely how many retries occur. Explicit uncertainty and operation identity let the interface offer an accurate recovery path.