Adds CanConnect API for use by health checks

[ajcvickers]

Fixes #13235

[ajcvickers]

/cc @divega @glennc @rynowak

I didn't add an overload that takes a delegate since, as Diego said previously, once the context instance has been resolved, then the health check can just execute any delegate against it directly without the need for a new method.

[ErikEJ]

Providers FYI?

[rynowak]

I didn't add an overload that takes a delegate since, as Diego said previously, once the context instance has been resolved, then the health check can just execute any delegate against it directly without the need for a new method.

This seems fine to me.

[rynowak]

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:

• Is is reasonable to expect the user to handle exceptions in their test delegate? or should we surround it with a try/catch.

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 DbContext.

[rynowak]

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?

[ajcvickers]

@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.

[rynowak]

Good stuff, thanks!

[divega]

👍