-
Notifications
You must be signed in to change notification settings - Fork 7
heartbeat hangs instead of failing #59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Most db errors render a JSON response, but this one's a failure to checkout a db conn from the pool. Due to our web framework (Rocket) this is done in a rocket request guard which currently lacks an easy way to customize error responses. It can be worked around though. |
pjenvey
added a commit
that referenced
this issue
Oct 8, 2018
and properly render their error responses Closes #59
pjenvey
added a commit
that referenced
this issue
Oct 9, 2018
and properly render their error responses (special casing heartbeat's handling) Closes #59
pjenvey
added a commit
that referenced
this issue
Oct 9, 2018
and properly render their error responses (special casing heartbeat's handling) also add cargo fmt -- --check Closes #59
pjenvey
added a commit
that referenced
this issue
Oct 9, 2018
and properly render their error responses (special casing heartbeat's handling) Closes #59
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On my machine, the
__heartbeat__
endpoint works fine when the database is up, but when I shut it down, the same endpoint just hangs, with megaphone dumping errors to console likeError: Can't connect to MySQL server on 'golden-cloud.local' (111)
. After about 30 seconds, I get an error response like this:Technically, I guess this is correct -- the 503 indicates that the heartbeat has failed -- but based on the structure of the JSON response, I assumed that it was possible for a response to have
status
beok
butdatabase
beerror
.The text was updated successfully, but these errors were encountered: