Correct Response code to send when DB connect fails
Which HTTP code is semantically correct to send in response to failing to connect to a database?
500 (internal server error) is a good catch-all, but it doesnt seem not be specific enough.
503 (service unavailable) is what im leaning towards but I'm not sure if it makes sense to say that the database is actually down at this time even if it fails to connect after the maximum retries
504 (gateway timeout) seems correct, but im not certain "gateway" describes what's going on
4XX is not correct as the server is responsible, 3XX 2XX and 1XX are obviously incorrect also.
I'm using this for a remote DB over the network (mongoDB), would the correct code be different if it were a local server, for example one running in docker, or the DB in a XAMPP/LAMP application?
32 Replies
I'm pretty sure an HTTP layer communicating with a database counts as a gateway
there's a good argument to be made for all three though
I think 504 is probably gonna be the right one up until the database goes down for real, at which point there's no way to differentiate that definite 503 from the 504 that's being sent due to libraries abstracting the details away
500 would solve that, but also be too bland.
ahh... good ol' http
I would say that 500 is the best option.
502/504 aren't right since accessing the DB isn't "working as a gateway" as I understand it.
503 is usually for things like the server being down for maintenance or is overloaded.
Based on https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#server_error_responses
Also against using 503, is that the service is available, only the DB connection is borked. The rest of the server is running fine (and is available)
500 is the generic catch-all for a reason. The rest are pretty specific errors
the argument I see for "working as a gateway" is that it's not the database server responding, but something Willster is writing that connects to the database, and exposes that through an HTTP interface
just had a look online for what a gateway actually is, apparently yeah, using a remote server doesn't seem to qualify.
as for 503, if your car works just fine but the front axle is borked, is it working? the rest of the car is running fine
And honestly, you don't want to send the front-end too much info about the server that could be used against you somehow. "DB connection timed out" is pretty specific and not at all important to the average user but could be used by a malicious user
Depends on if I want to use the radio or not :p
this is the best argument for 500, imho
I don't know what the rest of the server does so I don't know if the DB connection being down would count as the server being unavailable
yeah there's always that. same reason the 403 is basically unused
it only tries to connect when a request needs the db, so it will only send the error when the client attempts to interact with the DB, and the DB isn't responding correctly. all other operations which dont use the db will be unaffected
403 is used all the time with the Discord API. There are lots of people most weeks complaining that they don't know why they're getting a 403
If the rest of the service is still available without the DB connection than "Service Unavailable" isn't correct, is it? 😜
discord api stands to gain nothing from hiding those endpoints though... they've published detailed specifications for them. I guess with any endpoint that's public knowledge 403 works. but for something like an admin-only endpoint, it makes sense to just 404 that rather than saying "hey nerd, try crack this"
Discord uses 401 as "auth header missing/incorrect" and 403 as "auth sent can't do that". For example, a bot needs to be in a guild to send a message in one of its channels. So trying to send a message in a guild the bot isn't in is a 403 as the auth header is correctly formatted but the bot can't do that
shouldnt both of those be 401? 403 is "i won't authorise this for you at all" whereas 401 is "I may authorise this for you if you give the right credentials"
eh security by obscurity is mid anyway
🤷
just use
499 or 599 and the message see documentation page XProbably done that way for troubleshooting so they can mor easily discern what the issue is
seems like a lot of http codes are just suggestions rather than well defined categories
also don't worry too much about the exactly perfect code to use, at least you're using codes, I've worked with APIs where everything is a 200 but the error comes in as json
plus, you should document your API even if it's internal only
Yes, all of that
Internal consistency is key. And it's not like most people look at the error code. They just hit the refresh button and try again :p
So I guess my question for you is this: is knowing the issue was caused by a DB connection issue important? If so, use 504 and call it a day. If not, use 500 and call it a day
I'm gonna end up leaning on 500 a lot, so using 504 would probably make things a little easier
Boom, mic drop. There you go!
Easy peasy, 
and... done
also keep in mind 503 does have a "retry-after" header (optional)
just...something to keep in mind
bah, I'll just pop up a toast and let the user hit "submit" again or something. I can't deal with headers, too much of a pain
my rationale is if something can work without a header, then that header is useless. Turns out most headers are useless cos I really can't think of any headers to use as an example. all I can think of is
Location which is the one header I use somewhat oftenthat's a...rationale
like what the hell are these https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Standard_request_fields
List of HTTP header fields
HTTP header fields are a list of strings sent and received by both the client program and server on every HTTP request and response. These headers are usually invisible to the end-user and are only processed or logged by the server and client applications. They define how information sent/received through the connection are encoded (as in Conten...
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
I would disagree. I feel that using the correct response code is equally as important as choosing between
<main> <section> and <aside>. It's semantics, and it benefits both the developer and the user to have things be semantic. It's no use to anyone if your server will only response with 200, 404, or 500, especially when combined with no error response body, it's impossible to debug.