DistributedApplicationBuilder.Build leaves partial host service provider undisposed after host resolution failure

[akrock]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

DistributedApplicationBuilder.Build() can create a service provider and then
throw while resolving the host. When that happens, provider-owned disposable
services remain undisposed, while the caller receives no application or provider
through which cleanup can be performed.

This matters when Aspire is embedded in a long-lived process such as a test
runner or development tool. The build exception is catchable, and the containing
process can continue running with resources from the failed build still alive.

Actual behavior

DistributedApplicationBuilder.Build() delegates to the underlying generic host
builder. When that build throws after provider creation:

• no DistributedApplication is returned;
• the partial provider is not disposed;
• the provider is not exposed to the caller;
• provider-owned resources remain alive until process termination.

Expected Behavior

If host resolution fails after the service provider has been created,
DistributedApplicationBuilder.Build() should:

1. dispose the partial provider and its provider-owned services;
2. preserve the original host-construction exception as the primary exception;
3. leave no provider-owned resources active after Build() returns by throwing.

Steps To Reproduce

Create a .NET 10 console application:

dotnet new console --framework net10.0
dotnet add package Aspire.Hosting --version 13.4.6

Replace Program.cs with:

using Aspire.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

var builder = DistributedApplication.CreateBuilder(
    new DistributedApplicationOptions
    {
        Args = [],
        AssemblyName = typeof(DisposalProbe).Assembly.GetName().Name,
        ProjectDirectory = Directory.GetCurrentDirectory(),
        DisableDashboard = true
    });

DisposalProbe? probe = null;

builder.Services.AddSingleton<DisposalProbe>(
    _ => probe = new DisposalProbe());

builder.Services.AddSingleton<IHostLifetime>(services =>
{
    _ = services.GetRequiredService<DisposalProbe>();

    throw new InvalidOperationException(
        "Host construction failed after provider creation.");
});

try
{
    using var application = builder.Build();
}
catch (InvalidOperationException exception)
{
    Console.WriteLine(exception.Message);
}

Console.WriteLine(
    $"Provider-owned singleton created: {probe is not null}");

Console.WriteLine(
    $"Provider-owned singleton disposed: {probe?.IsDisposed}");

internal sealed class DisposalProbe : IDisposable
{
    public bool IsDisposed { get; private set; }

    public void Dispose() => IsDisposed = true;
}

Run it:

dotnet run

Output:

Host construction failed after provider creation.
Provider-owned singleton created: True
Provider-owned singleton disposed: False

The probe is created through the service-provider factory, rather than registered
as an externally owned singleton instance, so it should be disposed with its
owning provider.

Exceptions (if any)

The reproduction deliberately registers an IHostLifetime factory that throws:

System.InvalidOperationException: Host construction failed after provider creation.

The exception is caught by the reproduction, so the console output contains its
message rather than an unhandled-exception stack trace. No additional Aspire
exception is output. The reported problem is the provider-owned singleton state
that remains undisposed after the expected build exception is caught.

Aspire doctor output

Checking Aspire environment...

Aspire Environment Check

Aspire
✅ Aspire CLI version 13.4.6 (channel: stable)

.NET SDK
✅ .NET 10.0.102 installed (arm64)

Container Runtime
✅ Docker v29.5.3: running (auto-detected (default)) ← active

Environment
✅ HTTPS development certificate is trusted

Summary: 4 passed, 0 warnings, 0 failed

Aspire CLI Installations

Path:
/.dotnet/tools/.store/aspire.cli/13.4.6/
aspire.cli.osx-arm64/13.4.6/tools/net10.0/osx-arm64/aspire
Version: 13.4.6+87fe259e4fc244c599019a7b1304c85a1488f248
Channel: stable
Route: dotnet-tool
PATH status: not on PATH

Anything else?

Suggested direction

Please clarify the intended failed-build ownership contract.

A complete resolution would dispose the partial provider when host resolution
fails. The cleanup could be implemented in DistributedApplicationBuilder.Build()
or coordinated with the underlying generic-host implementation.

If Aspire intentionally cannot own that cleanup, a supported service-provider-
factory or host-builder customization seam would let an embedding caller assume
ownership. That is a fallback rather than the preferred behavior: callers should
not ordinarily need to replace the service-provider factory to make a failed
Build() release resources it created.

Reflection over the underlying host builder and global diagnostic interception
do not appear suitable as supported consumer workarounds.

Related work

• #4419: Allow configuring of the ServiceProvider on DistributedApplicationBuilder
  requests the customization seam described above. It does not cover disposal
  when the default provider has already been created and host resolution fails.
• #3093: Clean up distributed app builders to fix test failures
  addressed resources retained by builders that were never built. This report
  covers a different failure boundary: the provider is created, Build() throws,
  and the caller receives no host or provider to dispose.

[joperezr]

🤖 Aspire triage pass — 2026-07-22 06:39 UTC

Area: area-app-model
Kind: bug
Repro: yes-minimal — see the "Steps To Reproduce" section (self-contained net10 console app)
Affected version(s): 13.4.6 (latest: 13.4.6; no prior-working version cited — not established as a regression)
Severity: S3 — provider-owned disposables leak only on the Build() host-resolution failure path; narrow scenario (long-lived embedding host that catches the build exception and continues) with an effective workaround (treat a failed Build() as fatal / let the process exit)

Urgency: ⚪ backlog — no milestone
Reason: S3 edge failure-path leak, not a confirmed 13.4 regression (no prior 13.x baseline where this disposed correctly). Clean report in a core area — a human could reasonably pull this to 13.5, but it does not clear the servicing bar and defaults to backlog.

Suggested owner(s): @JamesNK (score ~57), backup @danegsta (score ~25)
Evidence:

• JamesNK merged 17 area-app-model PRs in the last 90d (e.g. Add PromptProgressAsync API to IInteractionService #18493, Fix user secrets escaping & and + as unicode sequences #18431, Fix flaky ResourceCommandServiceTests by disabling version check #18418, Route third-party dashboard logs under ThirdParty category and show Aspire warnings #18390, Fix resource service port collision in --isolated mode #18332; latest 2026-06-29) — by far the most active author in this area
• JamesNK closed 6 area-app-model issues as completed (e.g. File input: MaxFileSize XML doc should mention Dashboard's 1MB default fallback #18659, [13.3] Interaction Service is unaware if command is invoked from CLI #16720, Add TryGetByName #16388; latest 2026-07-08)
• danegsta closed 11 area-app-model issues as completed (e.g. AddViteApp HTTPS config injection fails in yarn workspaces monorepos (node_modules hoisting) #15853, --isolated does not randomize AppHost dashboard / OTLP / resource-service ports — concurrent runs collide #17872, WithArgs runs on startup even if WithExplicitStart is called on a service in 13.4.0 #17813; latest 2026-07-17) and merged Fix DCP monitor timestamp serialization #18798 (2026-07-16)
• CODEOWNERS: no path is cited in the issue body, so no CODEOWNERS entry contributed to the score

Confidence: medium
Needs human?: no

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.