Choose a term
Retry creates duplicate records?
Duplicate requests and safe retries
A timeout tells the caller it did not receive a result. It does not prove that the server did nothing. Before asking an agent to retry, identify the operation, the state it changes, and what must remain true when the same work arrives again.
Which problem do you have?
A retried request or duplicate delivery repeats a side effect.
idempotency. Define what counts as the same operation and how its result survives retries. The term page compares a repeated toggle with a repeated assignment and explains why external effects need more.
A retry or competing request creates duplicate records.
unique constraint. Enforce a non-null business key in the database. The runnable SQLite example schedules both existence checks before either insert, then contrasts an unconstrained table with a unique constraint. It models the overlap; test actual parallel connections on your database separately.
Related database changes can be left partly saved.
transaction. Group the database writes into one commit unit. The runnable SQLite example injects a failure between an inventory change and a reservation, then verifies rollback. This does not undo an external API call or define retry identity.
Several components ask for the same data simultaneously.
request deduplication. Share equivalent reads while pending, with account and resource scope in the key. The runnable example tests shared successes, separate users, and cleanup after a failure. This controls client reads; it does not make server writes idempotent.
What to ask the agent to verify
Name the invariant first: one logical record, one applied operation, or all related database changes together. Exercise a repeated delivery and overlapping callers. Then test a failure between the side effect and its completion record. Use the provider's documented retry and idempotency contract for external effects.
Keep the claim bounded
These mechanisms solve different parts of the problem. A disabled button protects one interface, and an in-memory map protects one process for a limited lifetime. Neither establishes durable handling across restarts and multiple servers.
Sources
Updated and sources checked . How we check content.