[pdonis]

> Part of the problem here is that we're confusing how do you structure the API (replay? 409? something else?) with how we implement the API.

It would seem to me that you would want "what happens if a second request comes in with the same idempotency key while the first is still in progress" to be part of the API, so clients would know what your server is going to do in that scenario.

[stickfigure]

Nobody cares. These are short lived transactions (generally milliseconds); collisions are a rare edge case; it's fine to block. One request succeeds, the other gets a dup error (or a replay).

You could invent your own more sophisticated idempotency API but good luck finding someone that wants to implement it or use it. What real-world problem are you trying to solve?

[pdonis]

> Nobody cares.

Meaning, clients don't care about the thing I asked about?

> What real-world problem are you trying to solve?

I'm trying to understand your answers to my questions. When there seems to me to be something missing, I ask about it.

[stickfigure]

Correct, clients don't care to be notified if some other short lived request is in flight.