services.AddHealthChecks missing overload that takes delegate for configuring HealthChecksOptions

[DamianEdwards]

We need to add the overload to Health Checks to enable passing an options configuration delegate when adding Health Checks to services, e.g.:

services.AddHealthChecks(options =>
{
    options.AllowCachingResponses = true;
}).AddCheck<MyHealthCheck>()

@rynowak @glennc

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[weichch]

@pranavkm @Kahbazi I'm curious about this issue, because it doesn't look valid to me.

The AddHealthChecks method has nothing to do with HealthCheckOptions. The HealthCheckOptions is the options class for HealthCheckMiddleware, and it's only settable when calling MapHealthChecks. So this issue looks similar to #18153.

The associated PR seems to have added an overload which takes Action<HealthCheckServiceOptions>, and it is not what @DamianEdwards asked for? Also, I'd be interested in what the new overload can do because HealthCheckServiceOptions only manages the health check registrations that are already manageable via AddCheck methods, unless we are thinking of what I raised today #26570.

[jacobslusser]

@DamianEdwards, as pointed out, the HealthCheckOptions is used in MapHealthChecks, not AddHealthChecks. Did you mean to say MapHealthChecks?

Currently we can do as you suggested like:

endpoints.MapHealthChecks("/health", new HealthCheckOptions()
{
    AllowCachingResponses = true
});

I can send a PR for another overload that uses a configuration delegate like this if that is the ask:

endpoints.MapHealthChecks("/health", options => {
{
    options.AllowCachingResponses = true;
};

[DamianEdwards]

Have to cast my mind way back, but I think @weichch is right and what I was referring to was the fact that the HealthCheckOptions should be configurable in the DI container. The middleware would thus have to be updated to take HealthCheckOptions from DI in the case an instance wasn't passed to MapHealthChecks.

[weichch]

@DamianEdwards I think you can already get an instance of HealthCheckOptions from DI if not provided to MapHealthChecks. The HealthCheckMiddleware accepts instance of IOptions<HealthCheckOptions> in the constructor, therefore if not passed, an instance is resolved from DI.

For example:

services.Configure<HealthCheckOptions>(opt =>
{
    opt.AllowCachingResponses = true;
});

// This automatically gets the options from DI
endpoints.MapHealthChecks("/health"); 

Unless we're talking about named option per different health check endpoint, which might require a new API to be added:

public static IEndpointConventionBuilder MapHealthChecks(
    this IEndpointRouteBuilder endpoints,
    string pattern,
    string name)

Usage:

services.Configure<HealthCheckOptions>("HealthCheckWithCachingResponses", opt =>
{
    opt.AllowCachingResponses = true;
});

endpoints.MapHealthChecks("/health", "HealthCheckWithCachingResponses"); 

[mu88]

Do I understand you correctly that there is nothing to fix/improve, therefore no good first issue? 🙂