[shiandow]

This seems to assume retrying a command should result in the same response, but I am not sure I agree.

Idempotency is about state, not communication. Send the same payment twice and one of them should respond "payment already exists".

[Jolter]

I don’t know if we’re reading the same article? The linked one states very plainly:

”Idempotency is about the effect

An operation is idempotent if applying it once or many times has the same intended effect.”

[shiandow]

I do not disagree with their definition of idempotency, but they silently assume resending the same result is the default. They discus this later on in the article but they do not seem to question why that might not be a good idea in the first place.

Edit: Perhaps it is my mental model that is different. I think it makes most sense to see the idempotency key as a transaction identifier, and each request as a modification of that transaction. From this perspective it is clearer that the API calls are only implying the expected state that you need to handle conflicts and make PUTs idempotent. Making it explicit clarifies things.

The article actually ends up creating the required table to make this explicit, but the API calls do not clarify their intent. As long as the transaction remains pending you're free to say "just set the details to X" and just let the last call win, but making the state final requires knowing the state and if you are wrong it should return an error.

If you split this in two calls there's no way to avoid an error if you set it from pending to final twice. So a call that does both at once should also crash on conflicts because one of the two calls incorrectly assumed the transaction was still pending.

[Animats]

Right. An operation is idempotent only if doing it twice has the same result as doing it once. If you have to worry about whether an operation has already been done, it's not idempotent. If you have to worry about order of operations, it's not idempotent.

What's being asked for here is eventual consistency. If you make the same request twice, the system must settle into a the same state as if it was done only once. That's the realm of conflict-free replicated data types, which the article is trying to re-invent.

   x = 1

is idempotent.

   x = x + 1

over a link with delay and errors is a problem that requires the heavy machinery of CRDTs.

[cocoto]

In your example, idempotency means same request + same state = same response. State becomes part of the request, that’s why it is hard.

[shiandow]

That's just deterministic behaviour.

For idempotency you literally just want f(state) = f(f(state)). Whether you achieve this by just doing the same thing twice (no external effects) or doing the thing exactly once (if you do have side effects) is not important.

But if you have side effects and need something to happen exactly once it seems a lot more useful to communicate this, rather than pretending you did the thing.

[adrianmsmith]

> But if you have side effects and need something to happen exactly once it seems a lot more useful to communicate this, rather than pretending you did the thing.

I think it depends on whether the sender needs to know whether the thing was done during the request, or just needs to know that the thing was done at all. If the API is to make a purchase then maybe all the caller really needs to know is "the purchase has been done", no matter whether it was done this time or a previous time.

And in terms of a caller implementing retry logic, it's easier for the caller to just retry and accept the success response the second time (no matter if it was done the second time, or actually done the first time but the response got lost triggering the retry).

[raffael_de]

> Send the same payment twice and one of them should respond "payment already exists".

You are hiding the relevant complexity in the term "same". What is here the same? I mean, if accidentally buy only 1 instead of two items of a product and then buy afterwards again 1 item. How is this then the same or not the same payment?

[mrkeen]

> What is here the same?

The idempotency key of the request

[raffael_de]

How and based on what is the idempotency key calculated which the clients sends with its request? In my double-purchase example above: when would the second purchase be requested with the same key or not?

[Xenoamorphous]

If it’s a retry of the same request it should have the same key. If it’s not a retry, a different one. I don’t see the issue.

If the client sends the same key but a different payload that’s a 400 or 409 in my eyes.

[shiandow]

It shouldn't, an error would be the right response.

[mrkeen]

1) Fresh UUID

2) Client's choice

[raffael_de]

now you are moving the core question to where the fresh UUID is calculated. a UUID is calculated or reused based on a process-defined decision.

[mrkeen]

It's not the 'core question'.

I can choose to purchase a 2nd item, or I can choose to retry purchasing the 1st item. The server making that choice for me is not idempotency.

Idempotency is the server supporting my ability to retry purchasing the 1st item, safe in the knowledge that they won't send me a 2nd one.

[TacticalCoder]

Not that it's a bad TFA but in addition to what you said, many/most of the edge cases mentioned in TFA are just as problematic whether idempotency is desired or not.

I mean:

> Maybe the first request created a local payment but crashed before publishing an event ...

I mean, yeah, sure. That's a problem. I can come up with another one:

"Maybe the ZFS disk array for the DB caught fire and died a horrible death and you now need to restore from backups".

But that's going to be a problem anyway.