From a user perspective: This is a terrible error message. A normal person doesn’t know what JSON is, doesn’t care about TdsServerTransID, and has no idea what to do next. No guidance. No retry hint. No contact support. Just raw backend noise.
But the problems go deeper than UX. Look closely at the response: "errorCode": "201"
201 is Accepted.
A 2xx status code means success in every HTTP-based system on the planet.
So this is not an HTTP status code, it’s a custom error code pretending to be success.
That’s one of the worst practices you can implement:
- monitoring may stay green
- alerts may never fire
- retries may not trigger
- analytics may count failures as success
Now read this part: "Unexpected system error"
That’s clearly an unhandled backend failure. This belongs to the 5xx class, not hidden inside a successful response body.
So what do we have here?
- A real server error
- Masked as a successful response
- Sent directly to the end user
- With zero recovery guidance
This is how bugs live in production for years. It looks like the backend returns a detailed error, but in reality it’s doing the opposite: it’s breaking error semantics, observability, and user experience at the same time.
And this is not a small detail.
Top comments (2)
Ah, the 'Schrödinger’s Payment'—simultaneously successful (at the protocol level) and a failure (at the logical level) until a frustrated user opens a support ticket. Using a 201 for a system error is like a waiter bringing you an empty plate and a bill, then telling the manager the 'delivery' was successful because the plate reached the table.
this is a painfully accurate example