Default to Terminal view for live terminal resources in dashboard console logs#18867
Default to Terminal view for live terminal resources in dashboard console logs#18867mitchdenny wants to merge 3 commits into
Conversation
…sole When navigating to the console page for a resource with WithTerminal() applied, the dashboard now defaults to the Terminal view when the resource is live (Running) so the active PTY is shown immediately. Non-running terminal resources stay on the Console view so pre-PTY hosting messages and post-PTY exit output remain visible. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3d677385-2441-4093-b928-4d75a9ea599c
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 18867Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 18867" |
There was a problem hiding this comment.
Pull request overview
Defaults running terminal-enabled resources to Terminal while retaining Console for inactive resources.
Changes:
- Selects Terminal when the resource state is
Running. - Adds tests for live and non-live defaults.
Show a summary per file
| File | Description |
|---|---|
src/Aspire.Dashboard/Components/Pages/ConsoleLogs.razor.cs |
Implements state-based default selection. |
tests/Aspire.Dashboard.Components.Tests/Pages/ConsoleLogsTerminalTests.cs |
Verifies Terminal and Console defaults. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Medium
This comment has been minimized.
This comment has been minimized.
SubscribeAsync runs both on resource selection (via OnParametersSetAsync when needsNewSubscription) and on filter changes (via ConsoleLogsManager.OnFiltersChanged, e.g. clearing console logs). The default-view logic unconditionally reset _activeView on every call, so a user who manually switched a running terminal resource to Console and then cleared the logs was snapped back to Terminal, overriding their choice. Add a resetView flag so the Console default and the Running -> Terminal flip only apply on actual selection changes; filter refreshes now preserve the current view. Add a regression test covering a filter update after a manual Console selection on a live terminal resource. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3d677385-2441-4093-b928-4d75a9ea599c
This comment has been minimized.
This comment has been minimized.
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
PR Testing ReportPR Information
Artifact Version Verification
Changes AnalyzedFiles Changed
Change Categories
Behavior under testWhen navigating to a resource's Console page, the dashboard should default to the Terminal view only when the resource has a live (Running) terminal attached. A manual switch to Console must be respected and must survive a subsequent Test Environment
Test Scenarios ExecutedScenario 1: Live terminal resource defaults to TerminalObjective: Navigating to Steps:
Evidence:
Observations: The terminal emulator is selected by default and is visibly live (streaming timestamps). Scenario 2: Non-terminal resource defaults to ConsoleObjective: Navigating to Steps:
Evidence:
Observations: A resource without a terminal still defaults to Console logs, so the change is correctly scoped to terminal-enabled resources. Scenario 3: Manual Console selection survives a clear-logs filter change (regression)Objective: Verify the specific bug found in code review — because Steps:
Evidence:
Expected Unhappy-Path Outcome: The view remains Console after clearing logs. Without the fix, the clear would flip the view back to Terminal because Complementary Automated CoverageThe PR adds/keeps a bUnit component suite in Summary
Overall Result✅ PR VERIFIED Recommendations
|
The field comment still described the pre-change behavior (view purely user-controlled, always defaults to Console on selection, no auto-switching). Update it to reflect that a live terminal resource now defaults to Terminal on selection while all other cases default to Console, and that later filter/clear refreshes preserve the current view. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3d677385-2441-4093-b928-4d75a9ea599c
Tests selector (audit mode)The full test matrix and all jobs still run in audit mode. The tests and jobs below are what selective CI would run under enforcement. 7 / 100 test projects · 4 jobs, from 2 changed files. Selected test projects (7 / 100)
Selected jobs (4)
How these were chosen — grouped by what changed🔧 📦 affected project 🧪 Job reasons
Selection computed for commit |
Description
Resources that opt into
WithTerminal()expose an interactive terminal (PTY) alongside their console logs on the dashboard's Console logs page. Previously, selecting such a resource always landed the user on the Console view, and they had to open the ⋯ menu and pick Terminal every time — even when the terminal was already live and was the surface they came to use.Now, when you navigate to the Console logs page for a terminal-enabled resource that is live (its state is
Running, so the PTY is active), the page defaults to the Terminal view. This makes the interactive terminal the first thing you see for a running resource, matching what most users expect when they click through to a resource with a terminal.Terminal-enabled resources that are not live still default to the Console view, so the useful output remains immediately visible:
Waiting/Starting): pre-PTY hosting messages such asWaitForand startup failures.Exited/Finished/FailedToStart): post-PTY exit output.Both views remain mounted at once (as before), so this only changes which pane is shown first — nothing is torn down or rebuilt, and the user can still flip between Console and Terminal from the ⋯ menu at any time.
User-facing usage
WithTerminal()to a resource:Running→ the Terminal view is selected by default.Waiting/Startingor after it has exited → the Console view is selected by default.The default is evaluated at selection time (i.e. when you navigate to the resource). A later
Waiting → Runningtransition does not auto-flip the view, which also avoids overriding a view you picked manually.Screenshots / Recordings
Implementation
The default-view selection lives in
ConsoleLogs.SubscribeAsync, which runs only on resource-selection change. After it detects a terminal-enabled resource, it now flips_activeViewtoConsoleLogsView.TerminalwhenselectedResource.IsRunningState(); otherwise the default staysConsole.Checklist
<remarks />and<code />elements on your triple slash comments?