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

Idempotence: What is it and why should I care?

cloudingmine.com

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Idempotence: What is it and why should I care?

#31

Post by flukus »

pmarreck wrote: post #5

One of the practical applications of this concept I've found is that I try to write idempotent database migrations (so rerunning the migration, which is a common necessity while you're developing it, but is also useful if problems occur, won't error). So in essence both the "up" and the "down" migrations are idempotent and warn if they are not (and why).

Database migrations are inherently stateful so I'm not a fan of indompodence here, it can leave the schema in some arbitrary states. I much prefer tools like flyway (https://flywaydb.org/) that are more deterministic, each migration will only be run once so you're going from known state to known state.

Re: Idempotence: What is it and why should I care?

#33

Post by tankerdude »

ageitgey wrote: post #18

This is vital if you are designing apis or clients that deal with charging a user money. It should be literally impossible for a user to accidentally get charged twice due to a flakey connection if you design correctly. The trick is to have the client generate a random 'idempotency key' (a uuid) to start each logical transaction and have the server use that id to prevent double charges of the same transaction. By alw…

Yup. This is actually an interview question that I go through to see if they know mechanisms to prevent the double charge, fulfillment, etc. problem.

Re: Idempotence: What is it and why should I care?

#34

Post by not_kurt_godel »

I find that the easiest way to reason about idempotency is thinking about what happens when a client incorrectly retries a request (that is, resubmits it even though it was successful the first time). You should always strive to make sure that the duplicate request is handled gracefully and without negative consequences as much as possible. Requests that mutate state should, as a general rule, accept the desired state as an explicit parameter - avoid toggles, increments, decrements, 'go to next step' types of calls. Idempotency tokens are another valid strategy, though they can be clunky to implement.

Re: Idempotence: What is it and why should I care?

#35

Post by drawkbox »

not_kurt_godel wrote: post #34

I find that the easiest way to reason about idempotency is thinking about what happens when a client incorrectly retries a request (that is, resubmits it even though it was successful the first time). You should always strive to make sure that the duplicate request is handled gracefully and without negative consequences as much as possible. Requests that mutate state should, as a general rule, accept the desired stat…

There was a story about toggles in apis on HN a few months ago [1][2], basically the toggle function was called for the garage door, which is clearly not idempotent, rather than an action like open/close so that is wasn't repeated. The toggle action led to opening and closing of the door repeatedly. Non idempotent requests are especially bad when tied to real physical machinery.

[1] https://twitter.com/rombulow/status/990684453734203392

[2] https://news.ycombinator.com/item?id=16964907

Re: Idempotence: What is it and why should I care?

#36

Post by wincy »

A comment about the site. On an iPhone X and I’d imagine other phone screens, the margins are huge. Like the margin takes up maybe 15% around the text, then there’s padding on the div taking up maybe 10-15% more space. So there’s 3-4 words per line without turning on reading mode.

Re: Idempotence: What is it and why should I care?

#37

Post by mlajszczak »

Idempotence can be very helpful when one strives for resiliency.

Suppose you have an application that processes tasks that (among others) call an external API. Both external API call and task processing can fail independently. Moreover, task processing can fail after API call succeeded. If you the external API is idempotent, you can simply retry on any task processing failure, no matter when it happened. It can simplify error handling a lot.

Re: Idempotence: What is it and why should I care?

#38

Post by JauntyHatAngle »

Interesting, never thought about applying idempotency to the more traditional programming areas like web dev, although I would like to think I develop my apps like this even without thinking about it in terms of idempotency.

For those who might not be in the know, this is a crucial concept for IaC through tools like Puppet/Salt/Ansible etc, as it allows you to think/program infrastructure configuration as a state rather than scripting everything and having to take account of all the minute states that may exist on a legacy or well entrenched system.

Re: Idempotence: What is it and why should I care?

#39

Post by morokhovets »

not_kurt_godel wrote: post #15
rhacker wrote: post #11

Earlier quoted context omitted.

Posting this to drive people crazy :) (only kidding) How about state changes as a side effect, with a near meaningless result. LockAccount('user') The account is now locked. LockAccount('user') Error: The account was already locked! However, the internal state of the user after the second operation remains the same. We also cannot use any of the information in the result as something meaningful as shown in these math…

A more idempotency-friendly API would be: setAccountLockStatus('user', LockStatus.LOCKED)

Or maybe ensureAccountLocked('user')?

Re: Idempotence: What is it and why should I care?

#40

Post by BoiledCabbage »

rectangletangle wrote: post #22
ageitgey wrote: post #18

This is vital if you are designing apis or clients that deal with charging a user money. It should be literally impossible for a user to accidentally get charged twice due to a flakey connection if you design correctly. The trick is to have the client generate a random 'idempotency key' (a uuid) to start each logical transaction and have the server use that id to prevent double charges of the same transaction. By alw…

This is solid advice. Another common trick is to disable the submit event when the submit button is clicked for the first time, preventing two requests from firing, when the user double clicks. Then re-enable the event, if the request fails. Ideally this is done in addition to server side nonce validation, and not as the only preventative measure, because browser differences, or network issues could cause a double re…

Restricting what the client can do isn't idempotency. Allowing the user to perform the same action (make the same api-call) multiple times, Nd your API coalesce them as if it were 1, is. The point and benefit of idempotency on this scenario is that you silently support "bad" behavior.
Post reply on HN