[✨ Triage] microsoft/aspire#15674 by MermaidIsla - `aspire dashboard` - Start an empty dashboard

[MihuBot]

Triage for microsoft/aspire#15674.
Repo filter: area-dashboard issues.
MihuBot version: 246635.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

Tool logs

microsoft/aspire#15674: `aspire dashboard` - Start an empty dashboard by MermaidIsla
Extracted 5 search queries: aspire dashboard CLI command to start an empty dashboard, unable to import telemetry into a new dashboard only into existing dashboard, standalone dashboard for telemetry requires restart workaround, aspire dash quick start dashboard from command line, use dashboard as visual AppHost playground export C# or TypeScript
Found 25 candidate issues

• Pull Request #15607 (Mar 26 2026) - Add 'aspire dashboard' CLI command
  Summary: Implements the requested CLI command to start a standalone Aspire Dashboard (foreground by default, with a --detach/background option). Key features: discovers the managed dashboard binary from the CLI bundle layout, supports pass‑through args to the dashboard process, and exposes detach vs foreground modes (foreground uses LayoutProcessRunner, detach uses DetachedProcessLauncher).
  Relevant discussion / takeaways:

  • This is the implementation referenced on the new issue — work is already in progress.
  • Review recommendations called out in the PR (important to keep in mind for final acceptance):
    • Add unit tests for pass‑through args (including handling of the "--" delimiter) and detach/foreground behavior (suggested to use an injectable process‑launcher abstraction to avoid spawning real processes in tests).
    • Strip the literal "--" delimiter before forwarding args (forward only tokens after "--").
    • Wrap process start/launch calls with try/catch and convert failures to a clear user error + a DashboardFailure exit code instead of letting exceptions bubble to a generic exit.
    • Use ExecutionContext.WorkingDirectory for the child process working directory (instead of Directory.GetCurrentDirectory()) for consistency with CLI semantics.
    • Ensure detached/foreground paths surface useful errors for common failure modes (missing bundle, permission errors, invalid binary).

• Pull Request #13682 (Dec 22 2025) - Add import telemetry
  Summary: Adds telemetry import UI and a TelemetryImportService (JSON + ZIP support) to the Dashboard so users can import telemetry into the dashboard UI. This is the feature the new issue references as motivating starting an “empty dashboard” from the CLI.
  Relevant discussion / takeaways:

  • Import/export telemetry exists now (server + UI), which makes a CLI command to start a standalone/empty dashboard more useful (you can start a clean dashboard instance and import telemetry into it).
  • Reviewers discussed guarding import functionality for hosted dashboards (config / env var to disable import in hosted environments like App Service / ACA) — consider adding equivalent CLI/binary flags or respecting existing config to avoid surprising hosted deployments.

• Issue #1556 (Jan 05 2024) - Support dashboard running without server
  Summary: Tracked making the dashboard function when there is no resource server available (standalone OTLP ingestion). Reported startup/rendering issues when run standalone; subsequent fixes applied in follow-up PRs.
  Relevant discussion / takeaways:

  • Historical problems: Dashboard assumed a resource server in some code paths (DashboardClient.WhenConnected caused crashes). Fixes were applied (and a smoke test was suggested) so the standalone executable renders even when not connected to a resource service. Important for the new CLI command which intends to start a standalone/empty dashboard — ensure the binary version the CLI launches includes these fixes and that the CLI sets the correct working directory / env to run the dashboard standalone.

• Issue #2248 (Feb 15 2024) - Running the Dashboard Docker Image
  Summary: Users ran into “DashboardClient is disabled” and static-file issues when running older dashboard images in a standalone container; later image updates fixed standalone runtime problems.
  Relevant discussion / takeaways:

  • When starting the standalone binary (or a container image) the working directory and static assets matter (and older images had bugs). The CLI must clearly detect and error when the chosen bundle/binary is incompatible or missing required assets and should document image/version expectations.

• Issue #9300 (May 14 2025) - aspire run stuck on "Starting Aspire dashboard..."
  Summary: aspire run sometimes hangs waiting for the dashboard to become healthy (e.g., due to cert or other startup errors). The CLI was waiting for a health signal indefinitely; proposals were made to detect terminal failure states/timeouts and surface actionable errors.
  Relevant discussion / takeaways:

  • Important lessons for the dashboard CLI command:
    • Don’t block indefinitely; detect terminal dashboard startup failures and surface clear troubleshooting guidance.
    • Consider adding timeouts or listening for the dashboard process exiting so the CLI can report the failure rather than hang.
    • There’s precedent in reviewers' suggestions on PR #15607 to catch process-start exceptions and return DashboardFailure with a helpful message.

• Issue #9386 (May 19 2025) - Support launching the dashboard on aspire run
  Summary: Request to automate launching the browser when starting the apphost; discussion moved to backlog for UX considerations.
  Relevant discussion / takeaways:

  • Related UX angle: the new aspire dashboard command should have clear UX expectations (foreground vs detached) and documentation about whether it opens a browser or just starts the server. Consider an option or note in docs for launching the browser or integrating with aspire run/extensions.

• Issue #4256 (May 22 2024) - Aspire Dashboard - Persist dashboard data
  Summary: Request to persist telemetry (instead of just in-memory circular buffer). Team discussed scope: not a full APM backend, but minimal persistence (e.g., flush-to-disk on graceful shutdown or simple SQLite) is of interest. The dashboard team later indicated minimal persistence would be provided in future releases.
  Relevant discussion / takeaways:

  • The new CLI command is useful for workflows around import/export and ephemeral dashboards — if minimal persistence lands, it may affect the default behavior for "empty" dashboards (how long they retain imports). Keep in mind persistence config (and where the CLI should write/read persisted data, e.g., default data directory or a flag).

• Pull Request #1717 (Jan 19 2024) - [dashboard-oop] Launch dashboard as exe (merged)
  Summary: Early work to run the dashboard as a separate executable (out-of-process), with discussion about how to set URLs, working directory and whether to prefer HTTP fallback.
  Relevant discussion / takeaways:

  • The CLI should set the correct environment (ASPNETCORE_URLS, working directory) when launching the managed dashboard binary to ensure static web assets and OTLP endpoints resolve correctly. PR #15607 already uses the layout discovery / process runner approach — validate it respects the lessons here.

• Issue #3450 (Apr 06 2024) - Make dashboard a separate apphost resource
  Summary: Recommendation to move dashboard logic into a distinct apphost resource (hidden by default) and use lifecycle hooks.
  Relevant discussion / takeaways:

  • The CLI’s discovery of the managed dashboard binary and layout should align with the resource model; starting a standalone dashboard via CLI should be consistent with how an apphost would add the dashboard as a resource.

• Issue #14733 (Feb 26 2026) - Standalone Aspire Dashboard doesn’t work with MCP
  Summary: MCP (local process controller) integration with standalone dashboard had problems (extension-side fetch failed to undefined). User expected either MCP support or docs indicating it’s unsupported.
  Relevant discussion / takeaways:

  • If aspire dashboard is intended to integrate with developer tooling (MCP / VS Code), confirm whether standalone dashboard is expected to be manageable via MCP. If not, consider hiding MCP UI affordances or show clear docs/error messages. The CLI command should not advertise MCP integration unless it's supported.

Other notes pulled across the related threads:

• Tests and UX: reviewers repeatedly asked for tests covering pass-through args, detach/foreground, and failure scenarios. The PR implementing the command already includes some tests but follow-ups are recommended.
• Error handling: callers want clear errors instead of generic crash; PR reviewers recommended catching process-start exceptions and returning a dashboard-specific exit code + user message. Also detect dashboard process exit in detached-mode and surface PID.
• Argument forwarding semantics: strip the "--" delimiter before forwarding vs accidentally forwarding it (affects patterns like aspire dashboard -- --urls http://...).
• Working directory semantics: prefer ExecutionContext.WorkingDirectory so detached child processes run in correct directory (static assets/relative paths depend on this).
• Security/config: telemetry import should be configurable/disableable for hosted dashboards; the standalone dashboard started by the CLI should respect configuration and clearly document defaults.

If helpful next steps: confirm PR #15607 status and address the reviewer items above (strip "--", add tests for pass-through + detach, robust exception handling with DashboardFailure exit code, use ExecutionContext.WorkingDirectory), and document expected behavior (does the command open a browser, where telemetry persistence/imports are stored, and how MCP/IDE integration is expected to behave).