Disable resilience handler in test builders

[afscrome]

Theory

The AddStandardResilienceHandler() calls in TestDistributedApplicationBuilder and AspireIntegrationTestFixture add automatic HTTP retry logic to all test HTTP clients. The hypothesis is that this masks genuine race conditions in integration tests: when a resource isn't truly ready to serve requests, the resilience pipeline silently retries until it succeeds — turning what should be a guaranteed, reproducible failure into an intermittent, flaky test.

Why this is particularly dangerous

The specific race being hidden is between:

1. A container resource starting up (image pull → container start → application boot → HTTP server ready)
2. An HTTP client firing retries against that resource while it's still starting

This race is almost never visible locally because:

• Your local hardware is typically faster than a CI agent
• Docker images are already pulled (or even have running containers to reuse)
• The resource is ready long before the first retry exhausts

In CI, however, the agent has to pull the image from scratch on every run. This means the resource startup takes significantly longer, and the resilience handler's retry budget can be exhausted before the HTTP server is ready — which is exactly what we see in the failures below. Without retries, the test fails fast and visibly every time; with retries, it passes most of the time but occasionally flakes when the machine is slow or under load.

The correct fix is not retries — it's a proper health check so that WaitForResourceHealthyAsync(...) means "the HTTP server is actually ready", not just "the container process started".

This PR removes the resilience handler from both test helpers and sets ASPIRE_TESTING_DISABLE_HTTP_CLIENT=true to prevent Aspire from adding its own HTTP client reliability defaults during tests.

Evidence

After making that removal, CI immediately surfaced 6 real failures across Ubuntu runners:

Test	Resource hit	Failure
Hosting.Azure.Extensions.Tests — AppHostTests.ResourceStartsAndRespondsOk	blobs-explorer (Azure Storage Explorer)	HttpRequestException → HttpIOException: response ended prematurely
Hosting.DbGate.Tests — AppHostTests.ResourceStartsAndRespondsOk	dbgate	Same
Hosting.MongoDB.Extensions.Tests — AppHostTests.ResourceStartsAndRespondsOk	dbgate (via .WithDbGate())	Same
Hosting.Redis.Extensions.Tests — AppHostTests.ResourceStartsAndRespondsOk	dbgate (via .WithDbGate())	Same
Hosting.PostgreSQL.Extensions.Tests — AppHostTests.ResourceStartsAndRespondsOk	dbgate (via .WithDbGate())	Same
Hosting.Java.Tests — JavaHostingComponentTests.AppResourceWillRespondWithOk("containerapp")	Java container app	Same

All 6 tests call WaitForResourceHealthyAsync(...) before issuing GET /, but none of the affected resources had an explicit HTTP health check registered — so "healthy" state was being reached before the HTTP server was actually ready to accept connections.

Changes

Remove resilience handlers from test helpers

• tests/CommunityToolkit.Aspire.Testing/TestDistributedApplicationBuilder.cs — removed .AddStandardResilienceHandler() and set ASPIRE_TESTING_DISABLE_HTTP_CLIENT=true to ensure aspire doesn't add the same resilience back.
• tests/CommunityToolkit.Aspire.Testing/AspireIntegrationTestFixture.cs — same

Add explicit HTTP health checks

• DbGate (src/CommunityToolkit.Aspire.Hosting.DbGate/DbGateBuilderExtensions.cs) — added .WithHttpHealthCheck("/health", ...). DbGate's upstream API exposes a dedicated /health endpoint, making this the correct readiness signal.
• Azure Storage Explorer (src/CommunityToolkit.Aspire.Hosting.Azure.Extensions/AzureStorageExplorerBuilderExtensions.cs) — added .WithHttpHealthCheck("/", ...). Upstream Helm/k8s manifests use / for readiness/liveness probes; no dedicated health endpoint exists.

Out of scope

The Java containerapp failure is handled by #1500 and is intentionally not fixed here.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://github.com/ghraw/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.sh | bash -s -- 1504

Or

• Run remotely in PowerShell:

iex "& { $(irm https://github.com/ghraw/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.ps1) } 1504"