[docs] Document dashboard bundle preparation status message - #1508
[docs] Document dashboard bundle preparation status message#1508aspire-repo-bot[bot] wants to merge 3 commits into
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
aspire-repo-bot
Bot
added
the
docs-from-code
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Frontend HTML artifact readyThe latest frontend build uploaded the This comment updates automatically when a new frontend build artifact is uploaded. |
There was a problem hiding this comment.
Pull request overview
Documents the aspire dashboard run startup messaging so users understand the (intentional) quiet period during dashboard bundle preparation and the subsequent status messages.
Changes:
- Added documentation describing the initial 200 ms grace period while preparing/extracting the dashboard bundle.
- Documented the conditional
Preparing dashboard bits...status message and the separateStarting dashboard...message once the process is launched.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
David Pine (IEvangelist)
left a comment
David Pine (IEvangelist)
left a comment
There was a problem hiding this comment.
Docs-accuracy review — automated (Phase A: claims vs source · Phase B: doc-tester)
Phase A source of truth: microsoft/aspire @ release/13.5 — SHA 45f7776ddb51ba976a32ece224ef8b23ed989a91
Claims extracted: 5 · ✅ verified: 5 ·
Phase B (doc-tester): 1 doc route + a live blind-user run of aspire dashboard run (CLI 13.5.0) · 🔴 critical: 0 · 🟡 warnings: 0 · 1 knowledge-gap note
The single added paragraph in aspire-dashboard-run.mdx accurately describes the startup sequence. Every factual claim matches the source on release/13.5, and the observable CLI behavior matched the docs in a live run. Marking Comment only to surface one Phase B knowledge gap (the cold-path message couldn't be independently reproduced on a warm cache).
Phase A — Claim verification
All 5 non-narrative claims verified against release/13.5 (45f7776). No contradicted or unverifiable claims, so there are no inline comments.
✅ Verified claims (5) with evidence
| # | Claim | Verdict | Evidence (microsoft/aspire @ 45f7776) |
|---|---|---|---|
| 1 | "The CLI initially prepares the dashboard bundle without showing a status." | ✅ verified | src/Aspire.Cli/Commands/DashboardRunCommand.cs:147-153 — layoutTask starts, then Task.WhenAny(layoutTask, Task.Delay(...)) returns without a status if prep finishes first. Comment (L149): "wait briefly before showing a status to avoid flicker during typical usage." |
| 2 | "If preparation is still in progress after 200 ms, it shows Preparing dashboard bits..." |
✅ verified | DashboardRunCommand.cs:24 s_bundleStatusDelay = TimeSpan.FromMilliseconds(200); L150 Task.WhenAny(layoutTask, Task.Delay(s_bundleStatusDelay)); L155-157 shows EnsuringDashboardBundle when the delay wins. |
| 3 | Literal status text Preparing dashboard bits... |
✅ verified | src/Aspire.Cli/Resources/DashboardCommandStrings.resx:144-145 — EnsuringDashboardBundle = "Preparing dashboard bits...". |
| 4 | "shows Preparing dashboard bits... until the bundle is ready" |
✅ verified | DashboardRunCommand.cs:155-157 — InteractionService.ShowStatusAsync(EnsuringDashboardBundle, () => layoutTask) holds the status while awaiting the layout task to completion. |
| 5 | "The CLI then launches the dashboard process and shows the separate Starting dashboard... status." |
✅ verified | Ordering: L88 EnsureDashboardBundleAsync → L142 ExecuteForegroundAsync → L399 StartAsync(...) (process launch) → L414-415 ShowStatusAsync(StartingDashboard, ...). DashboardCommandStrings.resx:141-142 StartingDashboard = "Starting dashboard...". |
Phase B — Doc-tester results (blind user; no microsoft/aspire source consulted)
Focus area: /reference/cli/commands/aspire-dashboard-run/ — the added paragraph on bundle-preparation status messages.
Routes / actions exercised:
https://aspire.dev/reference/cli/commands/aspire-dashboard-run/— loaded (HTTP 200). Confirmed the new paragraph slots cleanly between the "Any additional arguments…" and "To stop the dashboard…" paragraphs. (The paragraph itself is not on the deployed site yet, since this PR is unmerged.)- Live blind-user run of
aspire dashboard run(CLI13.5.0), capturing startup output.
Summary
| Category | Passed | Failed | Warnings |
|---|---|---|---|
| Content accuracy (observable) | 2 | 0 | 0 |
| CLI behavior | 2 | 0 | 0 |
| Links (changed content) | n/a — no links added | 0 | 0 |
Critical issues
None.
Passed checks
Starting dashboard...appears exactly as documented. Captured terminal output:Starting dashboard... Dashboard: http://localhost:18888/login?t=... OTLP/gRPC: http://localhost:4317 OTLP/HTTP: http://localhost:4318 Logs: C:\Users\...\.aspire\logs\cli_...log- Quiet initial preparation confirmed. No preparation status was printed before
Starting dashboard...(the dashboard bundle was already cached, so prep completed within the documented 200 ms window) — matches "initially prepares the dashboard bundle without showing a status." - Page renders correctly and the new paragraph reads clearly in context.
Warnings
None.
Knowledge gaps
- Cold-path
Preparing dashboard bits...not independently reproduced. In this run the bundle was already extracted, so preparation finished inside the 200 ms quiet window andPreparing dashboard bits...did not appear. Forcing the >200 ms path would require clearing/manipulating internal bundle-cache state, which is outside a normal blind user's scope. A user on a warm machine may simply never see this message. This is expected given the doc's conditional wording ("If preparation is still in progress after 200 ms…") — no doc change required.
Recommendations
- None blocking. Optional nicety: note that
Preparing dashboard bits...typically appears only on first run / cold cache — but the current conditional phrasing is accurate and sufficient.
Verdict: COMMENT — every non-narrative claim is verified against release/13.5, and the live CLI run matched the documented behavior. The only item surfaced is a Phase B knowledge gap (cold-path message not reproducible on a warm cache), which is not a documentation defect.
Automated docs-accuracy reviewer · Phase A read microsoft/aspire@release/13.5 (45f7776ddb51ba976a32ece224ef8b23ed989a91) · Phase B via doc-tester skill.
…ist-dapine/pr-1508-phase-wording
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Suppressed comments (1)
src/frontend/src/content/docs/reference/cli/commands/aspire-dashboard-run.mdx:38
- The description hard-codes a specific timing threshold (“after 200 ms”). If this value is an implementation detail that may change, the docs risk becoming stale. Consider describing this behavior without an exact duration (e.g., “after a short delay”), or explicitly call out that the delay is approximate/implementation-dependent if the exact value is guaranteed.
The CLI initially prepares the dashboard bundle without showing a status. If preparation is still in progress after 200 ms, it shows `Preparing dashboard bits...` until the bundle is ready. The CLI then launches the dashboard process and shows the separate `Starting dashboard...` status.
David Pine (IEvangelist)
left a comment
David Pine (IEvangelist)
left a comment
There was a problem hiding this comment.
Docs-accuracy review — automated (Phase A: claims vs source · Phase B: doc-tester)
Phase A source of truth: microsoft/aspire @ release/13.5 — SHA 45f7776ddb51ba976a32ece224ef8b23ed989a91
Claims extracted: 5 · ✅ verified: 5 ·
Phase B (doc-tester): 1 doc route + a live blind-user run of aspire dashboard run (CLI 13.5.0+45f7776) · 🔴 critical: 0 · 🟡 warnings: 0 · 1 knowledge-gap note
Revision note: This head (
6f2ad34) adds only a merge commit that pulls the base branch into the PR; the single added paragraph inaspire-dashboard-run.mdxis byte-identical to the previously reviewed revision (655e5b2d), and the Phase A source SHA is unchanged (45f7776). Re-verified in full anyway. Every factual claim still matches the source onrelease/13.5, and the observable CLI behavior matched the docs in a fresh live run. Marking Comment only to surface one Phase B knowledge gap (the cold-path message can't be independently reproduced on a warm cache).
Phase A — Claim verification
All 5 non-narrative claims verified against release/13.5 (45f7776). No contradicted or unverifiable claims, so there are no inline comments.
✅ Verified claims (5) with evidence
| # | Claim | Verdict | Evidence (microsoft/aspire @ 45f7776) |
|---|---|---|---|
| 1 | "The CLI initially prepares the dashboard bundle without showing a status." | ✅ verified | src/Aspire.Cli/Commands/DashboardRunCommand.cs:147-153 — layoutTask starts, then Task.WhenAny(layoutTask, Task.Delay(...)) returns without a status if prep finishes first. Comment (L149): "wait briefly before showing a status to avoid flicker during typical usage." |
| 2 | "If preparation is still in progress after 200 ms, it shows Preparing dashboard bits..." |
✅ verified | DashboardRunCommand.cs:24 s_bundleStatusDelay = TimeSpan.FromMilliseconds(200); L150 Task.WhenAny(layoutTask, Task.Delay(s_bundleStatusDelay)); L155-157 shows EnsuringDashboardBundle when the delay wins. |
| 3 | Literal status text Preparing dashboard bits... |
✅ verified | src/Aspire.Cli/Resources/DashboardCommandStrings.resx:144-145 — EnsuringDashboardBundle = "Preparing dashboard bits...". |
| 4 | "shows Preparing dashboard bits... until the bundle is ready" |
✅ verified | DashboardRunCommand.cs:155-157 — InteractionService.ShowStatusAsync(EnsuringDashboardBundle, () => layoutTask) holds the status while awaiting the layout task to completion. |
| 5 | "The CLI then launches the dashboard process and shows the separate Starting dashboard... status." |
✅ verified | Ordering: L88 EnsureDashboardBundleAsync → L142 ExecuteForegroundAsync → L399 StartAsync(...) (process launch) → L414-415 ShowStatusAsync(StartingDashboard, ...). DashboardCommandStrings.resx:141-142 StartingDashboard = "Starting dashboard...". |
Phase B — Doc-tester results (blind user; no microsoft/aspire source consulted)
Focus area: /reference/cli/commands/aspire-dashboard-run/ — the added paragraph on bundle-preparation status messages.
Routes / actions exercised:
https://aspire.dev/reference/cli/commands/aspire-dashboard-run/— loaded (HTTP 200, title "aspire dashboard run command | Aspire"). Confirmed the "Any additional arguments…" paragraph renders with its inlinecodespan, giving the insertion point for the new paragraph. (The new paragraph itself is not on the deployed site yet, since this PR is unmerged.)- Live blind-user run of
aspire dashboard run(CLI13.5.0+45f7776), capturing startup output.
Summary
| Category | Passed | Failed | Warnings |
|---|---|---|---|
| Content accuracy (observable) | 2 | 0 | 0 |
| CLI behavior | 2 | 0 | 0 |
| Links (changed content) | n/a — no links added | 0 | 0 |
Critical issues
None.
Passed checks
Starting dashboard...appears exactly as documented. Captured terminal output:Starting dashboard... Dashboard: http://localhost:18888/login?t=... OTLP/gRPC: http://localhost:4317 OTLP/HTTP: http://localhost:4318 Logs: C:\Users\...\.aspire\logs\cli_...log- Quiet initial preparation confirmed. No preparation status printed before
Starting dashboard...(the dashboard bundle was already cached, so prep completed within the documented 200 ms quiet window) — matches "initially prepares the dashboard bundle without showing a status." - Page renders correctly and the new paragraph reads clearly in context.
Warnings
None.
Knowledge gaps
- Cold-path
Preparing dashboard bits...not independently reproduced. In this run the bundle was already extracted, so preparation finished inside the 200 ms quiet window andPreparing dashboard bits...did not appear. Forcing the >200 ms path would require clearing/manipulating internal bundle-cache state, which is outside a normal blind user's scope. A user on a warm machine may simply never see this message. This is expected given the doc's conditional wording ("If preparation is still in progress after 200 ms…") — no doc change required.
Recommendations
- None blocking. Optional nicety: note that
Preparing dashboard bits...typically appears only on first run / cold cache — but the current conditional phrasing is accurate and sufficient.
Verdict: COMMENT — every non-narrative claim is verified against release/13.5, and the fresh live CLI run matched the documented behavior. The only item surfaced is a Phase B knowledge gap (cold-path message not reproducible on a warm cache), which is not a documentation defect.
Automated docs-accuracy reviewer · head 6f2ad3469896db68ace81350b81a6ad3ce5d5df7 · Phase A read microsoft/aspire@release/13.5 (45f7776ddb51ba976a32ece224ef8b23ed989a91) · Phase B via doc-tester skill.
|
Is it really documentation-worthy ? |
Documents changes from microsoft/aspire#18985
@JamesNKTargeting
release/13.5based on the source PR milestone13.5.Why
aspire dashboard runpreviously could appear idle while the CLI prepared or extracted the dashboard bundle. The source PR keeps the first 200 ms of bundle preparation quiet. If preparation is still in progress after that grace period, the CLI displaysPreparing dashboard bits...until the bundle is ready, then launches the dashboard process and displays the separateStarting dashboard...status.What changed
reference/cli/commands/aspire-dashboard-run.mdxto document the startup sequence: a quiet 200 ms preparation grace period,Preparing dashboard bits...if preparation continues, and then the separateStarting dashboard...status after the bundle is ready and the process is launched.Files modified
src/frontend/src/content/docs/reference/cli/commands/aspire-dashboard-run.mdx(updated)No new pages were created; this was a small update to an existing page.