Health Checks, Dependency Injection, and Scope

[KirkMunroSagent]

I'm facing a challenge with Health Checks and scope and I'm not quite sure what to do about it. My challenge seems to come down to this line of ASP.NET code.

Here's the issue:
We're using DI in Health Checks. I'm invoking Health Checks programmatically by DI'ing HealthCheckService into a controller and calling its CheckHealthAsync method. The controller method in question uses a policy that has a requirement authorization handler which references a scoped DI service that identifies who the caller is. That scoped "caller id" service is used later on in other services to get the caller id information, and since it's scoped, the information is available; however, if I try to get the caller id information from the same service DI'ed into my Health Check, the information is not available seemingly because of the line in question above, which creates a new scope for each health check that is run. Why create a new scope for every health check that is identified to be run according to the predicate?

Is the answer that Health Checks "support" DI, meaning that DI is only properly supported when the health check in question is invoked via ASP.NET's internal uris, but if you invoke Health Checks via the public HealthCheckService.CheckHealthAsync method, then your DI scope is reset for each health check, which may break how scoped DI works in some scenarios because services are injected in a brand new scope instead of being used in the current scope, so you'll lose any information that was being retained in a scope-injected DI service before you programmatically invoked the health check?

This seems like a bug to me.

If I invoke a health check via an endpoint that has a DI'ed HealthCheckService.CheckHealthAsync, that should be done using my current scope from the endpoint invocation instead of creating a new scope for each health check. Even if I invoke a set of health checks using an internal uri and ASP.NET's default invocation mechanism, I would have expected that to be done using a single scope for all health checks that are run instead of creating a new scope for each health check that is to be run based on the predicate that was passed in. Anything else seems contrary to how scoping and DI is designed to work, no? Otherwise the Health Check is DI'ing its services from a different container, losing access to anything scoped that may have been updated during authentication or during the invocation of the endpoint itself if it did any work with scoped services that it expected would be available to the Health Checks that it is about to run.

All of that said, does anyone have any idea how I can preserve my current scope when running health checks programmatically? I can always create my own ScopedHealthCheckService and DI that instead of HealthCheckService to perform the execution within the same scope, but I'd really prefer not copying all of that code just to skip that one line.

[hahn-kev]

Health checks support publishing health reports at regular intervals. In order to support this health checks can't depend on a check running as part of a request. I suspect the code in the health check service explicitly makes a new scope so that your checks don't accidentally depend on the request context (and to allow using scoped services in a health check), otherwise when you go to publish a health report it'll fail due to not being in the context of a web request.

The documentation should probably be explicit about this behavior. However it makes sense, the health of an application doesn't change depending on who's asking.
Though I could see the case where your health check hits a different database depending on the customer who's asking. For that use case I'd probably register a health check for each Db then when calling HealthCheckService.CheckHealthAsync pass in a predicate to filter out the Db health checks you don't care about.

[KirkMunroSagent]

Thanks for sharing those details @hahn-kev.

In order to support this health checks can't depend on a check running as part of a request.

Not sure I agree there. You can publish health reports at regular intervals for health checks that are not dependent on caller and that don't require authentication, while still offering up health checks that are caller-dependent that require authentication. Supporting one does not mean the other cannot be supported as well.

However it makes sense, the health of an application doesn't change depending on who's asking.

It might. As you mention, different databases for different customers. There's also a difference between core health checks (components in a service that are required to be running and healthy for the service itself to be considered healthy to anyone -- the service itself, it's database, possibly a cache it uses, etc.) and health checks for optional/configurable components that are used by a service but are not absolutely required to be running for it to be considered healthy, but that may be required by some customers depending on their use of the service. There's no need to expose certain health checks to a customer if said customer does not use those parts of a service, so the health of the application does have some perspective tied to it.

For that use case I'd probably register a health check for each Db then when calling HealthCheckService.CheckHealthAsync pass in a predicate to filter out the Db health checks you don't care about.

That approach requires a software update. Some of the perspective a customer may have on service health is simply based on configuration, and doesn't necessarily need a software update.