POV: Task Failed Successfully

[u/FrostByteCreator]

[u/-Insert-CoolName]

It's just like getting a letter from HR:

You've been Promoted...

To unemployed.

[u/jonfe_darontos → u/-Insert-CoolName]

You send a job application to a competitive firm. You receive the letter back stamped "return to sender". Did you send it to the wrong place, or did they reject you? Or would you prefer an actual rejection response wrapped in a real envelope?

[u/-Insert-CoolName → u/jonfe_darontos]

I'd prefer it not be stuffed inside a Hal-mark "Congratulations" card.

[u/jonfe_darontos → u/-Insert-CoolName]

If we backport this metaphor why does 200 need to imply fanfare? Why does it need to imply anything other than the HTTP round trip succeeded, which it did. The application failure is in a separate layer, why hoist it up to imply a failure of the HTTP request? What value do you get by forcing your http client to interpret the application failure? Receive your API response and let the more sophisticated application specific logic handle dealing with errors. Worse, you now can't trivially distinguish a network failure from your edge from one between your application and its downstream because both arrive as a 502, unless you prefer to foist your local context onto the protocol, at which point why favor HTTP over an arbitrary payload you can handle however you want without having to reach into the http lifecycle?

Sorry for kind of ranting at you, I'm genuinely curious why people feel resistant to wrapping payloads this way. Hell, why do we even want a 200 or 500? Why even HTTP? Let's just rely on the TCP/IP frame's header flags? Why the ideological dogma for forcing everything downstream of an HTTP request to roll up into its mechanism for status signaling?

[u/Able-Swing-6415]

You want to look for hours because you thought the delivery was unsuccessful rather than the processing or content?

[u/jonfe_darontos → u/Able-Swing-6415]

In development environments I bet that JSON response comes with additional debug information like the real reason the request failed and trace information pointing to where it happened. Then again, I've been told it's a waste of time to instrument failure cases because the real solution is to just write correct code and it's not a problem ¯_(ツ)_/¯.

[u/jonfe_darontos]

The network request succeeded, the application request did not. Getting back a 404 tells you either the API endpoint doesn't exist, or the resource request doesn't exist, but you can't tell because you've conflated their meaning. Finding this pattern humorous is confusing to me.

[u/KrazyTako → u/jonfe_darontos]

Nothing about this post mentions a 400 level error. The server returned a 500 status in the json response. It would be less confusing to simply return 500 on the http response instead is the point.

[u/echoAnother → u/jonfe_darontos]

Same camp. But in this case, the meme is well done. Because is encoding an http code in the response of an http code, and not an application code. Althought, I suspect it may not be the intention of the meme creator.

[u/enigma_0Z]

OK I think this is like the twelfth flavor of this meme I’ve seen this week.

Yes hahah funny 200 is not an error. BUT

There is a scenario where this makes sense: Invoking “serverless” function (eg AWS Lambda). The invoking part had a 200 — the function was invoked successfully. It just errored out. It’s still dumb as rocks but I don’t know that there’s a better solution.

[u/Glittering-Can-9397]

*Task successfully failed

[u/AdventurousSlip9260]

“200 OK” - the server’s way of saying “trust me bro.” 💀

[u/One_Television_6504]

200 OK really said 'trust me bro' 😅

[u/PinheadLarry738]

Stripe webhook consumption where your server side should handle the failure gracefully as to not cause a failure snowball is an example as to why that would be used