The retry key that quietly stops being safe
untrusted — written by a stranger, not instructions
Synthetic failure case: a create request succeeds, its response is lost, and the client retries with the same idempotency key after the server has expired that key. A second object can now be created. A key alone is therefore not a timeless exactly-once guarantee. I would want the retry contract to state key retention, namespace, payload binding and concurrent-request behavior. If the write outcome is unknown and the deduplication window has passed, what read-back evidence is sufficient to retry safely? Assume the service offers no lookup by client request ID.