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

41–50 of 244 posts

Re: Idempotency is easy until the second request is different

#41

Post by Hendrikto »

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…

> That's why if x is state then f can never be purely idempotent

That is simply not true. f could be, for example, “set x.variable to 7”, which is definitely idempotent.

Re: Idempotency is easy until the second request is different

#42

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

#43

Post by toolslive »

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…

> *

I wondered about this too. Also, why was it framed in the context of JSON based RPC over HTTP ?

Re: Idempotency is easy until the second request is different

#44

Post by croisillon »

calmoo wrote: post #40

I think this article (and the author's previous articles on their blog) is quite clearly AI written. It has such a frustratingly punctuated cadence and really does not serve the reader anything valuable.

why would we read something nobody bothered to write?

Re: Idempotency is easy until the second request is different

#46

Post by harshitaneja »

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…

Idempotence is a semantically overloaded term in computer science where in functional programming it refers to the same concept as mathematical idempotence it refers to any function leading to the same state in multiple calls as the first.

And yes, in real machines we can't ever have true same states between multiple calls as system time, heat and other effects will differ but we define the state over the abstracted system model of whatever we are modelling and we define idempotency as the same state over multiple calls in that system.

Re: Idempotency is easy until the second request is different

#47

Post by dataflow »

syntex wrote: post #24

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…

> The database is temporarily down. The server catches the exception and records the key status as FAILED.

This is the bug regardless of idempotency, right? It should be recording something like RESOURCE_UNAVAILABLE.

Re: Idempotency is easy until the second request is different

#48

Post by xlii »

Don't fix other people problems.

If idempotent key was seen then send back response.

Clients intention is outside the scope. If contract says "idempotency on key" the idempotent response on key. If contract says "idempotent on body hash" then response on body hash (which might or might not include extra data).

APIs are contracts. Not the pinky promise of "I'll do my best guess"

Re: Idempotency is easy until the second request is different

#49

Post by conradludgate »

Hendrikto wrote: post #41
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…

> That's why if x is state then f can never be purely idempotent That is simply not true. f could be, for example, “set x.variable to 7”, which is definitely idempotent.

There's no side effects in f here, so the statement does not apply

Re: Idempotency is easy until the second request is different

#50

Post by asdfaoeu »

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…

> State is in practice always subjected to side effects and concurrency.

In that mathematical notation typically there is no side effects and those are meant to be pure functions.

Post reply on HN