Resource waiting on itself deadlocks, and breaks `aspire start`

[afscrome]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I had a bizarre issue where aspire run worked fine, but aspire start was hanging until it timed out. Whilst aspire start was hanging, I couldn't even to an aspire ps to see what was going on. This caused my agent to have a lot of problems working out what the problem was.

I eventually tracked the problem down to managing to cause a resource to wait on itself. (specifically in the community toolkit causing the Otel collector to wait on itself)

Expected Behavior

There are a few things wrong here:

1. A resource waiting on itself shouldn't deadlock (or should throw an error earlier)
2. A resource stuck in the waiting state shouldnt' cause aspire start to fail.
3. Even if aspire start waits for something, aspire ps or other commands should work whilst resources start up so an agent has a chance to troubleshoot the problem if there are problems.

Steps To Reproduce

var builder = DistributedApplication.CreateBuilder(args);

var x = builder.AddContainer("nginx", "nginx")
    .WithHttpEndpoint(targetPort: 80);

// This throws
// x.WaitFor(x);

// But this does not, and causes the resource to wait infinitely
// as well as blocking `aspire start` 
x.WithAnnotation(new WaitAnnotation(x.Resource, WaitType.WaitUntilHealthy));

builder.Build().Run();

Exceptions (if any)

No response

Aspire doctor output

Aspire Environment Check
========================

Aspire
  ⚠️ Aspire CLI version 13.4.0-preview.1.26271.17 (channel: daily) is out of date. Latest version is 13.5.0-preview.1.26281.1 (channel: prerelease)  
       Run 'aspire update' to update Aspire CLI.       

.NET SDK
  ✅ .NET 10.0.103 installed (arm64)  

Container Runtime
  ✅ Docker v28.4.0: running (auto-detected (default)) ← active  

Environment
  ✅ HTTPS development certificate is trusted  
  ⚠️ HTTPS development certificate has an older version (v5)  
       Run 'aspire certs clean' to remove all certificates, then run 'aspire certs trust' to create and trust a new one.       
       See: https://aka.ms/aspire-prerequisites#dev-certs                                                                      
       Details:                                                                                                                
       Older certificate versions (< v4) may not support all certificate trust scenarios.                                      

Summary: 3 passed, 2 warnings, 0 failed
For detailed prerequisites: https://aka.ms/aspire-prerequisites

Aspire CLI Installations
========================

╭──────────────────────────────────────────┬────────────────────────────────────────────────────────────────────┬─────────┬───────────┬─────────────╮
│ Path                                     │ Version                                                            │ Channel │ Route     │ PATH status │
├──────────────────────────────────────────┼────────────────────────────────────────────────────────────────────┼─────────┼───────────┼─────────────┤
│ /Users/alex/.aspire/bin/aspire (current) │ 13.4.0-preview.1.26271.17+b5ce100e0b30660a9e33ba757adf098aad9ffc92 │ daily   │ (unknown) │ active      │
╰──────────────────────────────────────────┴────────────────────────────────────────────────────────────────────┴─────────┴───────────┴─────────────╯

Anything else?

No response

[joperezr]

🤖 Aspire triage pass — 2026-05-31 20:17 UTC

Area: area-app-model, area-cli
Kind: bug
Repro: yes-minimal — see code block in issue body (AddContainer + WaitAnnotation self-reference)
Affected version(s): 13.4.0-preview.1.26271.17 (latest preview: 13.5.0-preview.1.26281.1)
Severity: S2 — aspire start hangs until timeout with no workaround; aspire ps is also blocked, preventing diagnosis. Direct WaitFor(self) throws, but the lower-level WithAnnotation(new WaitAnnotation(self, ...)) path silently deadlocks.

Urgency: 🟡 vNext — recommend milestone 13.5
Reason: Real deadlock + DX gap (aspire ps should remain responsive while resources start). Reporter does not establish a 13.3 → 13.4 regression baseline, and the underlying wait-annotation machinery is not a new-in-13.4 feature, so this does not clear the (very high) 13.4 release-blocking bar one week from ship. Recommending 13.5 so it isn't lost in the backlog.

Suggested owner(s): @JamesNK (score 48), backup @mitchdenny (score 8)
Evidence:

• JamesNK merged the bulk of area-app-model PRs in the last 90d (e.g. Fix DistributedApplicationTestingBuilder dashboard with dynamic ports #17729, Use KnownConfigNames for resource service endpoint URL with legacy fallback #17385, Use OrdinalIgnoreCase for EnvironmentVariableName comparer #17194, CLI: Print app host CLI log path when connected to a running app host #17168, Improve version log messages in CLI, AppHost and dashboard #17163, Use ASPIRE_APPHOST_LOGLEVEL instead of cascading Logging__LogLevel__Default #17071, Use arguments for built-in resource commands #17021, Handle non-interactive interaction service availability for resource commands #16973)
• JamesNK also dominates recent area-cli work that touches the start/wait path (e.g. Fix TypeScript deadlock repro E2E test #17701, Fix CLI Ctrl+C/SIGTERM shutdown: responsive cancellation and double-signal bug #17588, Fix dashboard resource service scheme and generate HTTPS dev cert for non-.NET AppHosts #17454)
• mitchdenny owns /src/Aspire.Cli per CODEOWNERS — relevant for the aspire start / aspire ps responsiveness ask

Confidence: medium — area + owner are high confidence; the recommendation to defer past 13.4 is a judgement call given how close we are to ship and the lack of a stated regression baseline.
Needs human?: no

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

[afscrome]

The aspire start portion of this issue gets weirder. The same thing can be encountered if a resource enters the FailedToStart state, rather than waiting on itself.

builder.AddContainer("fake", "fake");

[davidfowl]

I tried a minimal repro against the reported CLI/AppHost SDK version and can reproduce the self-wait deadlock, but I could not reproduce aspire start or aspire ps failing once the CLI was installed under a short temp home.

Environment checked:

• OS: macOS arm64
• Aspire CLI: 13.4.0-preview.1.26271.17+b5ce100e0b30660a9e33ba757adf098aad9ffc92
• AppHost SDK: 13.4.0-preview.1.26271.17
• Install route: isolated temp install under /tmp/<redacted>

Minimal AppHost:

using Aspire.Hosting.ApplicationModel;

var builder = DistributedApplication.CreateBuilder(args);

var x = builder.AddContainer("nginx", "nginx")
    .WithHttpEndpoint(targetPort: 80);

x.WithAnnotation(new WaitAnnotation(x.Resource, WaitType.WaitUntilHealthy));

builder.Build().Run();

aspire start --project <scratch>/SelfWaitApp.csproj --non-interactive --format Json succeeded:

{
  "appHostPath": "<scratch>/SelfWaitApp.csproj",
  "appHostPid": "<pid>",
  "cliPid": "<pid>",
  "dashboardUrl": "https://localhost:<port>/login?t=<redacted>",
  "logFile": "<tmp-home>/.aspire/logs/<log>.log"
}

Exit code: 0

aspire ps --format Json also succeeded:

[
  {
    "appHostPath": "<scratch>/SelfWaitApp.csproj",
    "appHostPid": "<pid>",
    "sdkVersion": "13.4.0-preview.1.26271.17",
    "cliPid": "<pid>",
    "dashboardUrl": null,
    "logFilePath": "<tmp-home>/.aspire/logs/<log>.log"
  }
]

Exit code: 0

The resource itself is permanently stuck waiting on itself. aspire describe --format Json shows:

{
  "name": "nginx-<suffix>",
  "displayName": "nginx",
  "resourceType": "Container",
  "state": "Waiting",
  "waitingFor": [
    "nginx"
  ],
  "source": "nginx:latest",
  "properties": {
    "container.image": "nginx:latest",
    "container.lifetime": "Session",
    "resource.waitingFor": [
      "nginx-<suffix>"
    ]
  }
}

Exit code: 0

And aspire wait nginx --timeout 10 times out:

Timed out waiting for resource 'nginx' to be healthy after 10s.

Exit code: 17

So the app-model issue is reproduced: the low-level WaitAnnotation path can create a self dependency that leaves the resource in Waiting forever. The CLI start/ps failures were not reproduced in this isolated install; I did run into a separate macOS Unix-domain socket path length problem when the isolated install lived under a long scratch path, which went away when using a short /tmp/<redacted> home.