Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Idempotency is easy until the second request is different

blog.dochia.dev

Post reply on HN
Print view View original

21–30 of 244 posts

Re: Idempotency is easy until the second request is different

#21

Post by mrkeen »

raffael_de wrote: post #20
shiandow wrote: post #4

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".

> 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?

> What is here the same?

The idempotency key of the request

Re: Idempotency is easy until the second request is different

#22

Post by vanviegen »

> If you’re still in school, here’s a fact: you will learn as much or more every year of your professional life than you learned during an entire university degree—assuming you have a real engineering job.

This rubs me the wrong way. It's stated as fact without any trace of evidence, it is probably false, and it seems to serve no purpose but to make struggling students feel worse (and make the author feel superior).

Re: Idempotency is easy until the second request is different

#23

Post by raffael_de »

mrkeen wrote: post #21
raffael_de wrote: post #20

Earlier quoted context omitted.

> 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?

> What is here the same? The idempotency key of the request

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?

Re: Idempotency is easy until the second request is different

#24

Post by syntex »

yes I always thought it's an easy thing. but I changed my mind recently when I had to deal with it.

A lot little things you need to think of. For example.

Client sends a request. The database is temporarily down. The server catches the exception and records the key status as FAILED. The client retries the request (as they should for a 500 error). The server sees the key exists with status FAILED and returns the error again-forever. Effectively "burned" the key on a transient error.

others like:

- you may have Namespace Collisions for users... (data leaks) - when not using transactions only redis locking you have different set of problem - the client needs to be implmented correctly. Like client sees timout and generates a new key, and exactly once processing is broken - you may have race conditions with resource deletes - using UUID vs keys build from object attributes (different set of issues)

I mean the list can get very long with little details..

Re: Idempotency is easy until the second request is different

#25

Post by riz_ »

vanviegen wrote: post #22

> If you’re still in school, here’s a fact: you will learn as much or more every year of your professional life than you learned during an entire university degree—assuming you have a real engineering job. This rubs me the wrong way. It's stated as fact without any trace of evidence, it is probably false, and it seems to serve no purpose but to make struggling students feel worse (and make the author feel superior).

You're commenting on the wrong article.

Re: Idempotency is easy until the second request is different

#26

Post by [deleted] »

vanviegen wrote: post #22

> If you’re still in school, here’s a fact: you will learn as much or more every year of your professional life than you learned during an entire university degree—assuming you have a real engineering job. This rubs me the wrong way. It's stated as fact without any trace of evidence, it is probably false, and it seems to serve no purpose but to make struggling students feel worse (and make the author feel superior).

[deleted]

Re: Idempotency is easy until the second request is different

#27

Post by behaviors »

stavros wrote: post #2

Half of the mentioned issues are issues of atomicity, not idempotency. If I make a request, and the server crashes midway and doesn't send some crucial events, that's an issue whether or not I send a second request. From a cursory read, only the part up to "what if the second request comes while the first is running" is an idempotency problem, in which case all subsequent responses need to wait until the first one is…

If the atomic action is idempotent, you don't need a layer for repeating yourself. You hit the nail on the head. So much idempotency efforts are made because they never made the actions idempotent in the first place.

Re: Idempotency is easy until the second request is different

#28

Post by [deleted] »

vanviegen wrote: post #22

> If you’re still in school, here’s a fact: you will learn as much or more every year of your professional life than you learned during an entire university degree—assuming you have a real engineering job. This rubs me the wrong way. It's stated as fact without any trace of evidence, it is probably false, and it seems to serve no purpose but to make struggling students feel worse (and make the author feel superior).

[deleted]

Re: Idempotency is easy until the second request is different

#29

Post by [deleted] »

raffael_de wrote: post #16

Idempotency means f(x) = f(f(x)).* Here x is interpreted as state and f an action acting on the state. State is in practice always subjected to side effects and concurrency. That's why if x is state then f can never be purely idempotent and the term has to be interpreted in a hand-wavy fashion which leads to confusions regarding attempts to handle that mismatch which again leads to rather meandering and confusing and…

[deleted]

Re: Idempotency is easy until the second request is different

#30

Post by ahoka »

zinkem wrote: post #3

Idempotency is easy if you don't use mutable state in your middleware. Auth, logging, and atomicity are all isolated concerns that should not affect the domain specific user contract with your API. How you handle unique keys is going to vary by domain and tolerance-- and its probably not going to be the same in every table. It's important to design a database schema that can work independently of your middleware laye…

So idempotency is easy if your service does not do anything useful?
Post reply on HN