Programmer Humor

Doesn't matter, the client ignores the error anyways.

Getting only a message with no error indicator isn’t much better either

Ah, I see you too have run code in Azure Functions…

This is always how graphql works :)

I inherited a project where it was essentially impossible to get anything other than 200 OK. Trying to use a private endpoint without logging in? 200 OK unauthorized. Sent gibberish instead of actual request body format? 200 OK bad request. Database connection down? You get the point...

Lmao do they work at Oracle???

I may have run in your acquaintance work, stuff along the lines of

200 OK

{ error_code: s23, error_msg: "An error was encountered when performing the operation" }

If you happen to run into him, kindly tackle him in the groin for me.

Thanks!

Ugh this just reminded me that I ran into this exact issue a couple years ago. We were running jobs every hour to ingest data from an API into our data warehouse. Eventually we got reports from users about having gaps in our data. We dug into it for days trying to find a pattern, but couldn't pinpoint anything. We were just missing random pieces of data, but our jobs never reported any failures.

Eventually we were able to determine the issue. HTTP 200 with "error: true" in the response. Fml

I've seen the status code in a JSON response before: https://cloud.google.com/storage/docs/json_api/v1/status-codes#401-unauthorized

One reason I can think of for including it is that it may make it easier for the consumer to check the status code if it's in the JSON. Depending on how many layers of abstraction you have, your app may not have access to the raw HTTP response.

Although, yeah you lose the single source of truth though.

I had a similar one at a past work too. A test which was asserting a response status 500.

Like, instead of the test asserting the correct error/status code was being returned, it was instead asserting any error would simply getting masked as a 500.

Basically, asserting the code was buggy....

That made me angry a couple of times but I still miss that place sometimes.

I once worked on a project where the main function would run the entire code in a try-catch block. The catch block did nothing. Just returned 200 OK. Didn't even log the error anywhere. Never seen anything so incredibly frustrating to work on.

Why not POST /to/the/api?withCorrectErrorCodes?

My team recently migrated to graphql and they don't even do it right. The graphql layer still makes REST calls and then translates them to a gql format, so not only do we get no time or computing savings, we also get the bullshit errors

It make sense for a wrapper layer to do this and I had to fight against APIs that didn't. If I make a single HTTP call that wraps multiple independent API calls into one, then the overall HTTP code should reflect status of the wrapper service, and the individual responses should each have their own code as returned by the underlying services.

For example on one app we needed to get user names by user id for a bunch of users. To optimize this, we batched calls into groups. The API would fail with an error code if one of the user ids in the batch was bad or couldn't be found. That meant we wouldn't be getting data for any of the users in the batch and we didn't know which userId was bad either. Such a call should return 200 for the overall call and individual result for each id, some of which could be errors.

What about both? User supplies bad input? HTTP 400 with response body json describing the error in a standard format?

That's not what HTTP errors are about, HTTP is a high level application protocol and its errors are supposed to be around access to resources, the underlying QUIC or TCP will handle most lower level networking nuances.

Also, 5xx errors are not about incorrect inputs, that's 4xx.

Except of course that http has a myriad of response codes that are more useful than a 200 with an error body. This was a serious mistake of GraphQL imo