Aglet

Learn from API idempotency key collisions

The lasting lesson is that an idempotency key belongs to one logical operation for a documented lifetime. Preserve the collision or near miss, the key-generation input, and the result association that exposed it. Keep remote retention and unknown outcomes visible rather than assuming every retry is safe.

Keep the lesson for the next incident

  1. Write the key contract

    Document operation identity, key generation, scope, storage, retry lifetime, payload relationship, result association, and readback path. Separate read, write, and unknown outcomes. State who owns reconciliation when a response arrives after local timeout.

  2. Keep identity fixtures

    Retain one-operation retries, similar distinct operations, concurrent generation, process restart, missing key storage, and late response cases. Store synthetic identifiers, expected effects, and attempt count. Include the original collision shape without retaining sensitive payloads.

  3. Review key pressure

    Watch key reuse, missing associations, unknown writes, duplicate effects, and concurrent creation by client version. Assign an owner and threshold. Close the follow-up only when key and readback checks cover every operation class that can create a side effect.

What to carry forward

Close learning with key scope, operation identity rules, safe retry and reconciliation owners, fixtures, and review signals. Keep remote retention limits explicit. The durable outcome is a repeatable distinction between retrying one operation and creating another.

Technical background: Stripe documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow