You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello! We've noticed AddDbContextCheck does not report the reason that the check failed. This healthcheck is tied to our Kubernetes readiness check, so the app becomes inaccessible from the reverse proxy when the check fails, and it therefore becomes difficult to make the app try and execute a query to get an error message.
So if we have an issue with our database, which could be auth-related, network-related, etc. all we have to go off of is this log line repeated a lot:
Health check MyContext with status Unhealthy completed after 10013.4456ms with message 'null'
It can be particularly hard to debug the issue if it's related to the specific credentials that the app is using (especially if using Kerberos / trusted connections) or the network route between the app and the DB server.
Anyway, I noticed that I can fix this by passing in a customTestQuery, overriding the default CanConnectAsync-calling function with one that will throw an exception, because the message from the exception will be included in the failure result:
However the docs advise against throwing exceptions in the check:
Providing a customTestQuery will replace the use of CanConnectAsync to test database connectivity. An implementation of a test query should handle exceptions that can arise due to connectivity failure, and should return a pass/fail result. The test query should be be designed to complete in a short and predicatable amount of time.
I would like to ask why the above approach is not recommended, and whether there is an alternative way to return some more detailed information about why the check has failed. Thanks in advance!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello! We've noticed AddDbContextCheck does not report the reason that the check failed. This healthcheck is tied to our Kubernetes readiness check, so the app becomes inaccessible from the reverse proxy when the check fails, and it therefore becomes difficult to make the app try and execute a query to get an error message.
So if we have an issue with our database, which could be auth-related, network-related, etc. all we have to go off of is this log line repeated a lot:
Health check MyContext with status Unhealthy completed after 10013.4456ms with message 'null'
It can be particularly hard to debug the issue if it's related to the specific credentials that the app is using (especially if using Kerberos / trusted connections) or the network route between the app and the DB server.
Anyway, I noticed that I can fix this by passing in a
customTestQuery
, overriding the defaultCanConnectAsync
-calling function with one that will throw an exception, because the message from the exception will be included in the failure result:However the docs advise against throwing exceptions in the check:
I would like to ask why the above approach is not recommended, and whether there is an alternative way to return some more detailed information about why the check has failed. Thanks in advance!
Beta Was this translation helpful? Give feedback.
All reactions