Make aspire ps work when dashboard is unavailable.#16621
Make aspire ps work when dashboard is unavailable.#16621afscrome wants to merge 1 commit intomicrosoft:mainfrom
aspire ps work when dashboard is unavailable.#16621Conversation
`WaitForResourceHealthy` will hang indefinitely if the dashboard resource doesn't exist. Fail fast if the dashboard doesn't exist to avoid `aspire ps` hanging indefinitely. Co-authored-by: Copilot <copilot@github.com>
afscrome
requested review from
JamesNK,
danegsta,
davidfowl,
karolz-ms and
mitchdenny
as code owners
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Prevents GetDashboardConnectionInfoAsync / backchannel dashboard URL retrieval from hanging indefinitely when the Dashboard feature is disabled (i.e., no dashboard resource is present in the application model).
Changes:
- Added an early check for the Aspire Dashboard resource in
DashboardUrlsHelperto returnUnhealthyimmediately when absent. - Refactored endpoint resolution to assume the dashboard resource exists after the early check.
- Added a regression test to verify unhealthy/empty results are returned promptly when the dashboard resource is not registered.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| tests/Aspire.Hosting.Tests/Backchannel/AuxiliaryBackchannelRpcTargetTests.cs | Adds a test asserting GetDashboardUrlsAsync returns promptly with unhealthy state when the dashboard is disabled. |
| src/Aspire.Hosting/Backchannel/DashboardUrlsHelper.cs | Adds an early “dashboard resource present” check to avoid waiting forever when the dashboard is disabled, and simplifies endpoint selection. |
| var appModel = serviceProvider.GetService<DistributedApplicationModel>(); | ||
| var dashboardResource = appModel?.Resources.SingleOrDefault( | ||
| r => string.Equals(r.Name, KnownResourceNames.AspireDashboard, StringComparisons.ResourceName)) as IResourceWithEndpoints; | ||
|
|
||
| if (dashboardResource is null) | ||
| { | ||
| logger.LogDebug("Dashboard resource is not present in the app model. Returning unavailable state."); | ||
| return DashboardConnectionInfo.Unhealthy; | ||
| } |
There was a problem hiding this comment.
This changes behavior when DistributedApplicationModel is not registered in DI: appModel becomes null, dashboardResource becomes null, and the method now returns Unhealthy immediately—skipping the later fallback logic that can derive a URL from configuration. To avoid a regression, only return immediately when the app model is present and the dashboard resource is absent (e.g., if (appModel is not null && dashboardResource is null) ...), otherwise continue with the existing wait/fallback path.
| // called DisableDashboard()), return immediately rather than waiting forever for a resource | ||
| // event that will never arrive. | ||
| var appModel = serviceProvider.GetService<DistributedApplicationModel>(); | ||
| var dashboardResource = appModel?.Resources.SingleOrDefault( |
There was a problem hiding this comment.
SingleOrDefault will throw if there are multiple resources with the dashboard name, turning this into an unexpected exception path. If the goal is simply to detect presence/absence to avoid hanging, consider using FirstOrDefault (or otherwise handling duplicates explicitly with a clearer error) so the helper degrades more predictably under misconfiguration.
| var dashboardResource = appModel?.Resources.SingleOrDefault( | |
| var dashboardResource = appModel?.Resources.FirstOrDefault( |
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 16621Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 16621" |
Description
WaitForResourceHealthywill hang indefinitely if the dashboard resource doesn't exist. Fail fast if the dashboard doesn't exist to avoidaspire pshanging indefinitely when an app host is started without the dashboard.This is particularly useful for
DistributedApplicationTestingBuilderas it now means you can inspect a hanging test withaspire ps, without having to configure the dashboard in advance.This partially solves #15576 - at least of the case that the app host doesn't have a dashboard. It doesn't solve the breakpoint issue - this would probably require implementing some kind of timeout for RPC calls on the CLI.
Checklist
aspire.devissue: