fix(aspire): route CreateHttpClient through IHttpClientFactory

[thomhurst]

Summary

• Closes [Bug]: AspireFixture.CreateHttpClient bypasses IHttpClientFactory, silently ignoring ConfigureHttpClientDefaults from the AppHost #5956. AspireFixture<TAppHost>.CreateHttpClient constructed HttpClient directly from a cached SocketsHttpHandler when EnableTelemetryCollection was true, bypassing the AppHost's IHttpClientFactory. Any DelegatingHandler registered via ConfigureHttpClientDefaults or AddHttpClient in ConfigureBuilder was silently dropped.
• The runtime's built-in DiagnosticsHandler propagates traceparent/baggage on every HttpClient regardless of construction path, and Aspire's own App.CreateHttpClient already trusts dev certs via the factory's primary handler — so the telemetry branch wasn't doing anything telemetry-specific. Collapse to always delegate to App.CreateHttpClient. Dropped the unused _httpHandler field and its disposal.
• Added regression coverage in OtlpCorrelationIntegrationTests. The shared IntegrationTestFixture now registers a CountingDelegatingHandler via ConfigureHttpClientDefaults and exposes HttpHandlerInvocationCount (backed by a DI singleton — no static mutable state).

Test plan

• dotnet build TUnit.Aspire.Tests/TUnit.Aspire.Tests.csproj passes locally
• CI Docker integration suite runs CreateHttpClient_Invokes_Registered_DelegatingHandler and passes
• Existing OtlpCorrelationIntegrationTests still pass (handler is a pass-through, shouldn't affect OTLP correlation)

[claude]

Code Review

This is a clean, well-scoped fix. The root cause is correctly identified and the solution is appropriately minimal.

AspireFixture.cs

The collapse to a single delegation line is the right call. The previous EnableTelemetryCollection branch was creating a raw SocketsHttpHandler — no ActivityPropagationHandler, no DiagnosticsHandler — so the doc comment claiming it "automatically propagates W3C traceparent/baggage" was never true. The fix removes both the lie and the bug simultaneously.

Disposal cleanup is correct: removing _httpHandler?.Dispose() / _httpHandler = null from DisposeAsync follows from the field deletion.

IntegrationTestFixture.cs

Counter design is solid. Volatile.Read for the read + Interlocked.Increment for the write is the correct minimal pattern for a shared counter under concurrent access. Sealing both helper types is good practice.

Handler registration is idiomatic. AddSingleton<HttpHandlerInvocationCounter> + AddTransient<CountingDelegatingHandler> + AddHttpMessageHandler<CountingDelegatingHandler>() is the standard Typed Handler pattern — the transient handler gets a new instance per HttpClient pipeline but they all share the singleton counter through DI, which is what you want.

One minor note: HttpHandlerInvocationCount calls GetRequiredService<HttpHandlerInvocationCounter>() on every access. Since this is a test-only property called rarely, it's not a problem in practice — but if this property ever grows hot-path usage, caching the resolved singleton at initialization time would be cleaner.

OtlpCorrelationIntegrationTests.cs

The before-delta pattern (var before = ...; /* act */; Assert > before) is the right way to handle the shared fixture here: it doesn't assume the counter starts at zero (other tests may have already fired it), and it still catches a regression where the handler is never invoked. The test is as simple as it needs to be.

Overall: correct fix, clean simplification, good regression coverage. No blocking concerns.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}