Protocol
Reuse the operation identity when retrying the same intent
A retry should not introduce itself as a brand-new business request.
When it fits
- An interface supports idempotency and transient failures require retries.
When to avoid it
- A token field alone does nothing unless the receiver enforces it. Expired keys, changed scope and partially completed workflows need explicit handling.
Why it matters
An idempotency key identifies one intended operation, not merely a network attempt. Retain that key when retrying the same operation under the receiver's documented rules. A genuinely new intent needs its own identity, even when its payload happens to look identical.
Steps
- Confirm that this operation implements deduplication and read its scope and retention rules.
- Store the operation key with the original parameters before sending.
- Reuse the key for permitted retries; reject accidental parameter changes instead of silently reusing it.
An example
Retrying one account-creation request preserves its key. Creating a second account deliberately uses a different key.
Check your result
A controlled retry test produces one intended effect, and a separate intent remains possible.
Keep this limit in mind
- A token field alone does nothing unless the receiver enforces it. Expired keys, changed scope and partially completed workflows need explicit handling.
Connected ideas
Compare withMake the write conditional on the version you reviewed
Evidence and sources
Supported EC2 operations use client tokens to recognize repeated requests, with operation-specific scope and parameter rules.
Adding a token to an arbitrary request has no protective effect unless the receiver implements the corresponding contract.
Ensuring idempotency in Amazon EC2 API requests · Client tokens; Types of idempotency