-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Adds CanConnect API for use by health checks #13289
Conversation
Providers FYI? |
This seems fine to me. |
I would imagine that my usage of this would look something like: public async Task<HealthCheckResult> CheckHealthAsync(CancellationToken cancellationToken = default)
{
var context = _context; // Assume I already resolves the DbContext type from DI
if (!await context.Database.CanConnectAsync(cancellationToken))
{
return HealtCheckResult.Unhealthy(...);
}
var testDelegate = _testDelegate; // Assume the user provided a test delegate somehow
if (testDelegate != null && !(await testDelegate(context)))
{
return HealthCheckResult.Unhealthy(...);
}
return HealthCheckResult.Healthy(...);
} Open question from me:
The health system already handles exceptions that come from health checks, but they are treated differently than a 'graceful' failure. So it's worth knowing if users are likely to expect that throw == graceful failure from a test delegate using |
Another thing to point out and discuss. Given that this is a new API that providers need to opt in to, I was planning to document as part of the health check implementation that it will only work for providers that have implemented this interface. This means that we wouldn't put any bespoke error check in place for the case where a provider is in use that hasn't implemented the new API. So if you did this, you would see the health system report that the check failed ungracefully, and it would log the exception thrown by EF. Does that sound good enough? |
@rynowak I was envisioning it slightly differently in that if a delegate is provided, then I don't think calling CanConnect first is useful. Anything that the delegate does will likely open the connection as a first step anyway. With regard to exceptions, I think it is reasonable that the delegate handle any exceptions that should be treated simply as "unhealthy" and return false for those. Unhandled exceptions would then be treated in the normal ungraceful place. With regard to handling providers that don't implement this, what you suggest sounds fine. This will be rare anyway, because all relational providers inherit from the relational base class and so will get the default "Exists" implementation anyway--notice there is no special code for SQL Server or SQLite here. |
7e0998c
to
44c9f06
Compare
44c9f06
to
b977e0c
Compare
Good stuff, thanks! |
👍 |
Fixes #13235