# Idempotency: test a successful write with a lost reply

A timeout leaves the caller uncertain about whether the operation committed. This sequential local simulation drops the first response after writing. Repeating the same intended action creates two records without deduplication and returns one stored result with a supported action key.

## Worked example

The teaching script uses action_42 twice. The naive path creates records 1 and 2. The deduplicated path returns record 1 twice. This is an in-memory simulation; production behavior also depends on persistence, atomicity, concurrent requests, key expiry and changed-input handling.

## Copyable prompt

```text
Review [WRITE WORKFLOW] for retries after a lost response. Separate operation success from response delivery. Define how the same intended action is identified, where its result is persisted and what happens for changed payloads, concurrent requests and expired keys. Propose a local mock test. Do not claim that adding a header alone provides idempotency unless the receiving service supports and enforces it.
```

## Checklist

- Reuse the same action identity for the same intended write.
- Confirm that the receiving service enforces deduplication.
- Test success followed by response loss.
- Check concurrency, persistence, expiry and changed inputs.

## Further reading

[Stripe: idempotent requests](https://docs.stripe.com/api/idempotent_requests)