Fix HttpServiceEndpointResolver leak: share a single resolver instead of one per HTTP handler

[epricer-polly]

Fixes #7670.

Summary

AddServiceDiscovery creates a new HttpServiceEndpointResolver for every HTTP message handler that is built. Handlers are rebuilt on the normal HttpClientFactory handler-lifetime rotation, so a fresh resolver is allocated periodically for the life of the process. Both call sites are affected:

• the AddHttpMessageHandler delegate in AddServiceDiscovery(IHttpClientBuilder), and
• CreateHandler in ServiceDiscoveryHttpMessageHandlerFactory.

HttpServiceEndpointResolver is IAsyncDisposable and owns endpoint-refresh timers plus configuration change-token subscriptions, but ResolvingHttpDelegatingHandler wraps it and never disposes it. Each orphaned resolver stays rooted (by the runtime timer queue and the configuration root) and never becomes eligible for collection; its live timers keep firing, which shows up as a slow, uptime-correlated CPU climb. My two-day production heap diff for a minimal service (Azure Container Apps) showed the instance count grow from 0 to 199.

Fix

Register HttpServiceEndpointResolver as a singleton. Notably this is how it's done with the ServiceEndpointResolver registration in AddServiceDiscoveryCore, and resolve it at both sites. It has no per-client state and caches watchers per service name internally, so a single shared instance is correct and is disposed once with the container.

Tests

Adds HttpServiceEndpointResolverSharingTests:

• AddServiceDiscoveryCore_RegistersResolverAsSingleton: the resolver is registered and resolves to a single shared instance.
• AddServiceDiscovery_HttpClient_HandlerUsesSharedResolverSingleton: the resolver captured by the built ResolvingHttpDelegatingHandler is the same container-owned singleton.

Both tests fail against the current code and pass with this change.

[epricer-polly]

@dotnet-policy-service agree company="Polly Insurance, LLC"

[Copilot]

Pull request overview

This PR fixes an uptime-correlated leak/CPU climb in Microsoft.Extensions.ServiceDiscovery by ensuring HttpServiceEndpointResolver is shared (singleton) instead of being reallocated on every HttpClientFactory handler rotation. This aligns the HTTP resolver’s lifetime with the container so its timers and configuration subscriptions are disposed once with the service provider.

Changes:

• Register HttpServiceEndpointResolver as a singleton in AddServiceDiscoveryCore.
• Update both HTTP handler construction paths to resolve and reuse the singleton resolver.
• Add tests validating singleton registration and that ResolvingHttpDelegatingHandler uses the shared resolver instance.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
test/Libraries/Microsoft.Extensions.ServiceDiscovery.Tests/HttpServiceEndpointResolverSharingTests.cs	Adds tests asserting the resolver is registered as a singleton and reused by the HTTP handler.
src/Libraries/Microsoft.Extensions.ServiceDiscovery/ServiceDiscoveryServiceCollectionExtensions.cs	Registers HttpServiceEndpointResolver as a singleton to prevent per-rotation allocations/leaks.
src/Libraries/Microsoft.Extensions.ServiceDiscovery/ServiceDiscoveryHttpClientBuilderExtensions.cs	Updates AddServiceDiscovery(IHttpClientBuilder) to use the singleton resolver instead of instantiating a new one per handler build.
src/Libraries/Microsoft.Extensions.ServiceDiscovery/Http/ServiceDiscoveryHttpMessageHandlerFactory.cs	Updates factory to inject and reuse the singleton resolver when creating handlers.

[jeffhandley]

I think there might be a regression here for existing disposal scenarios. Registering HttpServiceEndpointResolver as a singleton appears to make the root provider track it once a service-discovery handler is created. Since the resolver implements only IAsyncDisposable, synchronous ServiceProvider.Dispose() may then throw, whereas previously the resolver was not container-owned.

Please add test coverage for existing synchronous provider disposal, along the lines of the code below. Ideally, establish the passing baseline before this change—rebasing and adding the test in an earlier commit is one option—so we can confirm whether this PR changes the behavior.

[Fact]
public void AddServiceDiscovery_HttpClient_SynchronousProviderDisposalDoesNotThrow()
{
    var services = new ServiceCollection();
    services.AddHttpClient("test").AddServiceDiscovery();

    using var provider = services.BuildServiceProvider();
    using var handler = provider
        .GetRequiredService<IHttpMessageHandlerFactory>()
        .CreateHandler("test");
}

If those tests do show a change in synchronous disposal behavior, please preserve synchronous provider disposal—such as by adding a safe synchronous disposal path for the resolver.

[epricer-polly]

Restructured the PR baseline-first, as @jeffhandley suggested. He was correct, I introduced a regression.

Now 3 commits:

1. test: add baseline for synchronous provider disposal. AddServiceDiscovery_HttpClient_SynchronousProviderDisposalDoesNotThrow (your snippet) against unmodified main. Passes.
2. fix the leak, add the regression: share HttpServiceEndpointResolver as a singleton - the singleton registration. Fails.
3. fix the regression: preserve synchronous provider disposal for the shared resolver. HttpServiceEndpointResolver (and its ResolverEntry and ServiceEndpointWatcher) now implement IDisposable alongside IAsyncDisposable. the synchronous path releases the timers and configuration. Passes again.