Flush logs before terminal resource notifications

[David Fowler (davidfowl)]

Description

Fast-failing containers and executables could reach a terminal state before DCP stdout/stderr logs were forwarded to the host logger. That made DistributedApplicationTestingBuilder failures difficult to diagnose because WaitForResourceAsync could return before the relevant logs were visible.

This change flushes current DCP logs to active resource-log subscribers before terminal state notifications are published. The synchronous subscription path is internal and used by ResourceLoggerForwarderService; WatchAsync keeps its existing async stream semantics for dashboard/backchannel consumers. Snapshot/follow overlap is deduped with count-based matching so repeated identical log lines are preserved.

User-facing behavior

When a resource fails during startup, test code that waits for the resource to fail can include the container or executable stdout/stderr in captured host logs.

Validation

• ./restore.sh && ./build.sh --build /p:SkipNativeBuild=true
• ResourceLoggerServiceTests, including repeated stress runs
• ResourceLoggerForwarderServiceTests
• DCP resource logging tests
• ResourceFailureLoggingTests.ExecutableDoesNotExist
• ResourceFailureLoggingTests.ContainerExitsImmediatelyAfterStart
• Manual playground CLI E2E: temporary fast-failing Alpine container, aspire wait ... --status down, then aspire logs showed aspire-cli-fast-fail-e2e

Fixes: #10218

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 18539

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 18539"

[Copilot]

Pull request overview

This PR fixes missing crashing-container/executable logs in DistributedApplicationTestingBuilder scenarios (issue #10218). Fast-failing resources could reach a terminal state (Exited/FailedToStart/Finished) before DCP's follow log stream forwarded stderr/stdout to the host logger, so WaitForResourceAsync could return before the relevant logs were visible. The change flushes a non-follow DCP log snapshot to active resource-log subscribers before publishing the terminal state notification, and routes ResourceLoggerForwarderService through a new internal synchronous Subscribe path that guarantees those logs reach ILogger before the terminal notification unblocks waiters.

Changes:

• Adds an internal synchronous Subscribe/WaitForCompletionAsync/HasActiveSubscribers/AddLogs surface to ResourceLoggerService, with occurrence-based dedup so overlapping snapshot/follow log batches don't duplicate while preserving repeated identical lines.
• DcpResourceWatcher flushes a follow: false log snapshot before publishing terminal OnResourceChangedContext, gated on logs being available and an active subscriber; ResourceLoggerForwarderService switches from async WatchAsync to synchronous Subscribe + WaitForCompletionAsync.
• Adds extensive unit/integration tests covering subscription ordering, completion, dedup, concurrency, terminal-flush ordering, and executable/container startup-failure log visibility.

Show a summary per file

File	Description
src/Aspire.Hosting/ApplicationModel/ResourceLoggerService.cs	Adds internal Subscribe, WaitForCompletionAsync, HasActiveSubscribers, AddLogs (with dedup); completion signaling in Complete(); removes GetInternalLogger.
src/Aspire.Hosting/Dcp/DcpResourceWatcher.cs	Flushes a non-follow log snapshot before publishing terminal state; extracts HasLogsAvailable; follow stream now uses AddLogEntries(skipExisting:true).
src/Aspire.Hosting/ResourceLoggerForwarderService.cs	Switches forwarding to synchronous Subscribe + WaitForCompletionAsync; broadens caught cancellation to OperationCanceledException.
tests/Aspire.Hosting.Tests/ResourceLoggerServiceTests.cs	Adds tests for dedup, subscription ordering, completion, active-subscriber state, and concurrency stress.
tests/Aspire.Hosting.Tests/Dcp/DcpExecutorTests.cs	Adds test asserting terminal-state snapshot is flushed before the terminal notification.
tests/Aspire.Hosting.Tests/Dcp/TestKubernetesService.cs	Extends fake to expose the follow flag to log-stream callbacks.
tests/Aspire.Hosting.Tests/ResourceFailureLoggingTests.cs	Adds ExecutableDoesNotExist failure-log visibility test plus assertion helpers.
tests/Aspire.Hosting.Containers.Tests/ResourceFailureLoggingTests.cs	Adds ContainerExitsImmediatelyAfterStart failure-log visibility test plus assertion helpers.

Review details

• Files reviewed: 8/8 changed files
• Comments generated: 0
• Review effort level: Medium

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[David Pine (IEvangelist)]

PR Testing Report

PR Information

• PR Number: Flush logs before terminal resource notifications #18539
• Title: Flush logs before terminal resource notifications
• Author: davidfowl
• Head Commit: a06c4d9ddfdcb2be488641a155b00ab751fdcbcf
• Fixes: Still missing crashing container logs in 9.3 & 9.4 preview in tests #10218
• Tested At: 2026-06-29 (Windows, local temp dir + Docker Desktop 29.5.3)

Artifact Version Verification

• Expected Commit (PR head): a06c4d9
• Installed CLI version: 13.5.0-pr.18539.ga06c4d9d
• PR source worktree HEAD: a06c4d9ddf Flush logs before terminal resource notifications
• Status: ✅ Verified (dogfood CLI artifact + source worktree both at PR head)

Changes Analyzed

Files Changed

• src/Aspire.Hosting/ApplicationModel/ResourceLoggerService.cs (+254/-14) — new internal synchronous Subscribe, AddLogs/AddLogEntries, WaitForCompletionAsync, HasActiveSubscribers; count-based dedupe for overlapping snapshot/follow lines.
• src/Aspire.Hosting/Dcp/DcpResourceWatcher.cs (+57/-10) — FlushCurrentLogsAsync flushes a DCP log snapshot into active subscribers before publishing terminal-state notifications; flush is gated on HasActiveSubscribers so dashboard-less runs don't pay for an extra snapshot read.
• src/Aspire.Hosting/ResourceLoggerForwarderService.cs (+9/-3) — switched from WatchAsync to the new synchronous Subscribe + WaitForCompletionAsync path for stronger ordering into host ILogger.
• Tests: ResourceLoggerServiceTests (+372), Aspire.Hosting.Tests/ResourceFailureLoggingTests, Aspire.Hosting.Containers.Tests/ResourceFailureLoggingTests, Dcp/DcpExecutorTests, Dcp/TestKubernetesService.

Change Categories

• CLI changes
• Hosting changes (resource logging / DCP watcher / forwarder)
• Dashboard changes
• Template / Component changes
• CI infrastructure changes
• VS Code extension changes
• Test changes

Root cause / fix: Fast-failing containers and executables could reach a terminal state (Exited/FailedToStart) before DCP stdout/stderr was forwarded to the host logger, so WaitForResourceAsync could return before the relevant logs were visible — making DistributedApplicationTestingBuilder failures hard to diagnose. The fix flushes current DCP logs to active subscribers before the terminal notification is published.

Test Scenarios Executed

Scenario 1: Fast-failing container logs captured (CLI dogfood E2E)

Objective: Confirm a container that prints output then immediately exits non-zero has its stdout/stderr captured and visible via the real PR CLI.
Coverage Type: Happy path (real PR artifact)
Status: ✅ Passed

Steps:

1. aspire new aspire-empty (file-based AppHost).
2. Added AddContainer("fastfail", "alpine").WithImageTag("3.20").WithEntrypoint("/bin/sh").WithArgs("-c", "echo FASTFAILMARKER18539; echo SECONDLINE18539 1>&2; exit 1").
3. aspire start --isolated, aspire wait fastfail --status down, aspire logs fastfail, aspire stop.

Evidence (aspire logs fastfail):

[fastfail] FASTFAILMARKER18539
[fastfail] SECONDLINE18539

• FASTFAILMARKER18539 (stdout) present: True
• SECONDLINE18539 (stderr) present: True
• Resource reached down and logs from the same startup attempt were present.

---

Scenario 2: Fast-failing executable logs captured (CLI dogfood E2E — unhappy path)

Objective: Confirm an executable resource that exits immediately with a non-zero code surfaces its stdout/stderr.
Coverage Type: Unhappy path (real PR artifact)
Status: ✅ Passed

Steps:

1. Fresh aspire new aspire-empty.
2. Added AddExecutable("badexe", "cmd.exe", ".", "/c", "echo EXEFAILMARKER18539 && echo EXESTDERR18539 1>&2 && exit 7").
3. aspire start --isolated, aspire wait badexe --status down, aspire logs badexe, aspire stop.

Evidence (aspire logs badexe):

[badexe] [sys] Starting process...: Cmd = C:\Windows\system32\cmd.exe, Args = ["/c", "echo EXEFAILMARKER18539 && echo EXESTDERR18539 1>&2 && exit 7"]
[badexe] EXEFAILMARKER18539
[badexe] EXESTDERR18539

• EXEFAILMARKER18539 (stdout) present: True
• EXESTDERR18539 (stderr) present: True

Expected Unhappy-Path Outcome: Executable exits non-zero (exit 7) → resource reaches terminal down, and the stdout/stderr emitted before exit is captured in aspire logs. ✅ Met.

---

Scenario 3: PR source tests — deterministic fix validation

Objective: Run the PR's own unit/integration tests, which directly assert that resource logs are present before the terminal state unblocks the wait (the race the PR fixes). Built from an isolated worktree at PR head.
Coverage Type: Deterministic regression/unit validation
Status: ✅ Passed

Steps: git worktree add at a06c4d9, restore.cmd, then targeted dotnet test (MTP filters, quarantined/outerloop excluded).

Test selection	Project	Result
ResourceLoggerServiceTests (full class, 18 incl. 3 concurrency/stress tests)	Aspire.Hosting.Tests	✅ 18/18
ResourceFailureLoggingTests.ExecutableDoesNotExist + DcpExecutorTests.ResourceLogging_TerminalStateFlushesSnapshotBeforeNotification	Aspire.Hosting.Tests	✅ 2/2
ResourceFailureLoggingTests.ContainerExitsImmediatelyAfterStart (Docker)	Aspire.Hosting.Containers.Tests	✅ 1/1
ResourceLoggerForwarderServiceTests (full class)	Aspire.Hosting.Testing.Tests	✅ 3/3

New behavior tests confirmed present and passing (in ResourceLoggerServiceTests):
AddLogEntries_OverlappingSnapshotAndFollow_DedupesByOccurrence, AddLogEntries_RepeatedIdenticalLines_ArePreservedWhenDedupingOverlap, Subscribe_DeliversBacklogBeforeLiveLogs_WithContinuousLineNumbers, WaitForCompletionAsync_CompletesWhenResourceLogStreamCompletes, HasActiveSubscribers_ReturnsFalseAfterCompletion, GetAllAsync_DoesNotReplayNonInMemoryEntries, and the three concurrency tests below.

Stress validation (race-condition determinism): The 3 concurrency tests
(Subscribe_ConcurrentAddLogEntries_DeliversEachEntryOnceWithUniqueLineNumbers,
AddLogEntries_ConcurrentOverlappingBatches_DedupesByOccurrence,
SubscribeAndDispose_ConcurrentWithLogging_DoesNotThrowOrDeadlock)
were run 5 consecutive times → 3/3 passed every iteration (no flakiness, no deadlock).

Note: tests executed on the net8.0 TFM as selected by the runner.

Summary

Scenario	Status	Notes
1. Fast-fail container logs (CLI E2E)	✅ Passed	stdout + stderr captured; resource down
2. Fast-fail executable logs (CLI E2E, unhappy path)	✅ Passed	exit 7; stdout + stderr captured
3. PR source tests (24 tests)	✅ Passed	0 failures across 4 projects
3b. Concurrency stress (5× repeat)	✅ Passed	deterministic, no deadlock

Overall Result

✅ PR VERIFIED

The fix behaves as described: fast-failing containers and executables now surface their stdout/stderr through the real PR CLI's aspire logs, and the PR's own deterministic tests — including the snapshot-flush-before-terminal-notification test and the concurrency/dedupe tests — pass reliably (including under repeated stress).

Recommendations

• None blocking. The change is well covered by new deterministic tests.
• Optional: CI could run the three concurrency tests under repeated iterations if future regressions in the snapshot/follow dedupe path are a concern (they were stable in 5× local stress here).

[David Pine (IEvangelist)]

Reviewed the log-ordering changes and the accompanying tests. The fix and its coverage (snapshot flushed exactly once before the terminal notification, dedup-by-occurrence, concurrency, continuous line numbering, completion semantics) look solid.

Two notes left inline:

1. Performance concern — the per-batch dedup (skipExisting: true) now runs for every resource's full lifetime rather than only around the one-time terminal flush, adding O(backlog) work per follow batch whenever subscribers are attached (the always-on forwarder always is).
2. Minor correctness note — a related low-confidence edge case where cross-batch identical lines could be deduped.

Approving — neither blocks merge, but #1 is worth addressing for chatty resources.

Summary: 1 performance concern, 1 minor correctness note.

[David Fowler (davidfowl)]

PR Testing Report

PR Information

• PR Number: Flush logs before terminal resource notifications #18539
• Title: Flush logs before terminal resource notifications
• Head Commit: a06c4d9
• Tested At: 2026-06-29T17:23:00Z

Artifact Version Verification

• Expected Commit: a06c4d9
• Installed Version: 13.5.0-pr.18539.ga06c4d9d
• Status: ✅ Verified - installed PR CLI version contains the PR head short SHA a06c4d9d.

Changes Analyzed

Files Changed

• src/Aspire.Hosting/ApplicationModel/ResourceLoggerService.cs - Modified
• src/Aspire.Hosting/Dcp/DcpResourceWatcher.cs - Modified
• src/Aspire.Hosting/ResourceLoggerForwarderService.cs - Modified
• tests/Aspire.Hosting.Containers.Tests/ResourceFailureLoggingTests.cs - Modified
• tests/Aspire.Hosting.Tests/Dcp/DcpExecutorTests.cs - Modified
• tests/Aspire.Hosting.Tests/Dcp/TestKubernetesService.cs - Modified
• tests/Aspire.Hosting.Tests/ResourceFailureLoggingTests.cs - Modified
• tests/Aspire.Hosting.Tests/ResourceLoggerServiceTests.cs - Modified

Change Categories

• CLI changes detected
• Hosting changes detected
• Dashboard changes detected
• Template changes detected
• Client/Component changes detected
• VS Code extension changes detected
• CI infrastructure changes detected
• Test changes detected

Test Scenarios Executed

Scenario 1: Dogfood artifact verification

Objective: Verify that testing used the PR CLI/package artifact for PR #18539, not a local or channel install.
Coverage Type: Artifact verification
Status: ✅ Passed

Steps:

1. Installed the PR dogfood CLI with get-aspire-cli-pr.sh using --install-path, --skip-path, and --skip-extension.
2. Read the installed binary version from the isolated install path.
3. Compared the installed version against PR head commit a06c4d9ddfdcb2be488641a155b00ab751fdcbcf.

Evidence:

• Version file: evidence/version.txt
• Installed CLI path: isolated dogfood install under the temp workspace

Observations:

• Installed version was 13.5.0-pr.18539.ga06c4d9d, which matches the PR head short SHA.

---

Scenario 2: Fresh AppHost fast-failing container logs

Objective: Verify a fresh AppHost using the PR package hive exposes stderr from a fast-failing container after aspire wait --status down observes the resource down.
Coverage Type: Happy path / Docker E2E
Status: ✅ Passed

Steps:

1. Created a fresh app from the PR hive with aspire new aspire-starter.
2. Reduced the generated AppHost to a minimal project-based AppHost to avoid unrelated generated Web project compilation during this log-focused scenario.
3. Added an Alpine container resource:

   builder.AddContainer("fastfail-container", "alpine")
       .WithEntrypoint("sh")
       .WithArgs("-c", "echo pr-testing-container-sentinel >&2; exit 42");

4. Started the AppHost with the PR CLI using aspire start --isolated --apphost <csproj>.
5. Ran aspire wait fastfail-container --status down.
6. Ran aspire logs fastfail-container --tail 100 --timestamps.
7. Stopped the AppHost.

Evidence:

• AppHost source: evidence/container-fast-fail/apphost-source.txt
• Start output: evidence/container-fast-fail/start-output.txt
• Wait output: evidence/container-fast-fail/wait-output.txt
• Logs output: evidence/container-fast-fail/logs-output.txt
• Describe output: evidence/container-fast-fail/describe-output.json
• Result: evidence/container-fast-fail/result.txt

Observations:

• aspire wait reported fastfail-container down.
• aspire logs included pr-testing-container-sentinel after the wait completed.
• Docker was available; the Docker daemon diagnostic is captured in evidence/docker-info.txt.

---

Scenario 3: Fresh AppHost fast-failing executable logs

Objective: Verify a fresh AppHost using the PR package hive exposes stderr from a fast-failing executable after aspire wait --status down observes the resource down.
Coverage Type: Happy path / executable E2E
Status: ✅ Passed

Steps:

1. Created a fresh app from the PR hive with aspire new aspire-starter.
2. Reduced the generated AppHost to a minimal project-based AppHost to avoid unrelated generated Web project compilation during this log-focused scenario.
3. Added an executable resource:

   builder.AddExecutable("fastfail-executable", "/bin/sh", ".", "-c", "echo pr-testing-executable-sentinel >&2; exit 42");

4. Started the AppHost with the PR CLI using aspire start --isolated --apphost <csproj>.
5. Ran aspire wait fastfail-executable --status down.
6. Ran aspire logs fastfail-executable --tail 100 --timestamps.
7. Stopped the AppHost.

Evidence:

• AppHost source: evidence/executable-fast-fail/apphost-source.txt
• Start output: evidence/executable-fast-fail/start-output.txt
• Wait output: evidence/executable-fast-fail/wait-output.txt
• Logs output: evidence/executable-fast-fail/logs-output.txt
• Describe output: evidence/executable-fast-fail/describe-output.json
• Result: evidence/executable-fast-fail/result.txt

Observations:

• aspire wait reported fastfail-executable down.
• aspire logs included pr-testing-executable-sentinel after the wait completed.

---

Scenario 4: Source regression tests

Objective: Verify the focused unit, DCP ordering, executable failure, and Docker container failure tests added or affected by the PR.
Coverage Type: Unit/regression/negative-boundary coverage
Status: ✅ Passed

Steps:

1. Ran repo restore with ./restore.sh.
2. Ran ResourceLoggerServiceTests.
3. Ran DcpExecutorTests.ResourceLogging_TerminalStateFlushesSnapshotBeforeNotification.
4. Ran ResourceFailureLoggingTests.ExecutableDoesNotExist.
5. Ran Aspire.Hosting.Containers.Tests.ResourceFailureLoggingTests.ContainerExitsImmediatelyAfterStart.

Evidence:

• test-logs/resource-logger-service-tests.log - 18 tests passed
• test-logs/dcp-terminal-flush-test.log - 1 test passed
• test-logs/executable-failure-log-test.log - 1 test passed
• test-logs/container-failure-log-test.log - 1 test passed

Observations:

• Resource logger stress/dedupe/completion tests passed.
• The deterministic DCP terminal-state flush ordering test passed.
• Executable and container failure-log regressions passed.

Setup Observations

• aspire-empty currently generates a file-based AppHost. In this local temp path under /var/folders, follow-up commands could not match the running file-based AppHost path, so the final scenarios used a project-based AppHost path instead.
• A direct aspire-starter generated app failed to build because the generated Web project could not resolve its Components namespace. That is unrelated to this PR's hosting-log changes, so the final scenarios kept the fresh generated AppHost project but removed unrelated generated project references before adding the failing resources.

Summary

Scenario	Status	Notes
Dogfood artifact verification	✅ Passed	Installed version 13.5.0-pr.18539.ga06c4d9d matched PR head.
Fresh AppHost fast-failing container logs	✅ Passed	aspire logs included pr-testing-container-sentinel after wait --status down.
Fresh AppHost fast-failing executable logs	✅ Passed	aspire logs included pr-testing-executable-sentinel after wait --status down.
Source regression tests	✅ Passed	21 focused tests passed across hosting and container test projects.

Overall Result

✅ PR VERIFIED

Recommendations

• Keep the deterministic ResourceLoggerServiceTests and DCP terminal-state ordering test as the primary regression guards.
• Keep the Docker-backed failure-log test as an E2E smoke test with diagnostic log output on assertion failure.

[Karol Zadora-Przylecki (karolz-ms)]

See my suggestion for DcpResourceWatcher--you probably want a full test pass again after that

[Copilot]

Review details

• Files reviewed: 8/8 changed files
• Comments generated: 2
• Review effort level: Medium

[github-actions]

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.

51 / 98 test projects · 5 jobs, from 10 changed files.

Selected test projects (51 / 98)

Aspire.Cli.EndToEnd.Tests, Aspire.Cli.Tests, Aspire.Dashboard.Components.Tests, Aspire.Dashboard.Tests, Aspire.EndToEnd.Tests, Aspire.Hosting.Analyzers.Tests, Aspire.Hosting.Azure.Kubernetes.Tests, Aspire.Hosting.Azure.Kusto.Tests, Aspire.Hosting.Azure.Tests, Aspire.Hosting.Blazor.Tests, Aspire.Hosting.Browsers.Tests, Aspire.Hosting.CodeGeneration.Go.Tests, Aspire.Hosting.CodeGeneration.Java.Tests, Aspire.Hosting.CodeGeneration.Python.Tests, Aspire.Hosting.CodeGeneration.Rust.Tests, Aspire.Hosting.CodeGeneration.TypeScript.Tests, Aspire.Hosting.Containers.Tests, Aspire.Hosting.DevTunnels.Tests, Aspire.Hosting.Docker.Tests, Aspire.Hosting.DotnetTool.Tests, Aspire.Hosting.EntityFrameworkCore.Tests, Aspire.Hosting.Foundry.Tests, Aspire.Hosting.Garnet.Tests, Aspire.Hosting.GitHub.Models.Tests, Aspire.Hosting.Go.Tests, Aspire.Hosting.JavaScript.Tests, Aspire.Hosting.Kafka.Tests, Aspire.Hosting.Keycloak.Tests, Aspire.Hosting.Kubernetes.Tests, Aspire.Hosting.Maui.Tests, Aspire.Hosting.Milvus.Tests, Aspire.Hosting.MongoDB.Tests, Aspire.Hosting.MySql.Tests, Aspire.Hosting.Nats.Tests, Aspire.Hosting.OpenAI.Tests, Aspire.Hosting.Oracle.Tests, Aspire.Hosting.Orleans.Tests, Aspire.Hosting.PostgreSQL.Tests, Aspire.Hosting.Python.Tests, Aspire.Hosting.Qdrant.Tests, Aspire.Hosting.RabbitMQ.Tests, Aspire.Hosting.Redis.Tests, Aspire.Hosting.RemoteHost.Tests, Aspire.Hosting.Seq.Tests, Aspire.Hosting.SqlServer.Tests, Aspire.Hosting.Testing.Tests, Aspire.Hosting.Tests, Aspire.Hosting.Valkey.Tests, Aspire.Hosting.Yarp.Tests, Aspire.Managed.Tests, Aspire.Playground.Tests

Selected jobs (5)

cli-starter, deployment-e2e, extension-e2e, polyglot, typescript-api-compat

---

How these were chosen — grouped by what changed

⚠️ 43 of the 51 selected test projects come from a single change — src/Aspire.Hosting/ApplicationModel/ResourceLoggerService.cs.

🔧 src/Aspire.Hosting/ApplicationModel/ResourceLoggerService.cs (changed source)
→ 43 via the project graph

show 43

Aspire.Hosting.Analyzers.Tests (2 hops), Aspire.Hosting.Azure.Kubernetes.Tests (2 hops), Aspire.Hosting.Azure.Kusto.Tests (2 hops), Aspire.Hosting.Azure.Tests, Aspire.Hosting.Blazor.Tests (2 hops), Aspire.Hosting.Browsers.Tests (2 hops), Aspire.Hosting.CodeGeneration.Go.Tests, Aspire.Hosting.CodeGeneration.Java.Tests, Aspire.Hosting.CodeGeneration.Python.Tests, Aspire.Hosting.CodeGeneration.Rust.Tests, Aspire.Hosting.CodeGeneration.TypeScript.Tests, Aspire.Hosting.DevTunnels.Tests (2 hops), Aspire.Hosting.Docker.Tests (2 hops), Aspire.Hosting.DotnetTool.Tests (2 hops), Aspire.Hosting.EntityFrameworkCore.Tests (2 hops), Aspire.Hosting.Foundry.Tests (2 hops), Aspire.Hosting.Garnet.Tests (2 hops), Aspire.Hosting.GitHub.Models.Tests (2 hops), Aspire.Hosting.Go.Tests (2 hops), Aspire.Hosting.JavaScript.Tests (2 hops), Aspire.Hosting.Kafka.Tests (2 hops), Aspire.Hosting.Keycloak.Tests (2 hops), Aspire.Hosting.Kubernetes.Tests (2 hops), Aspire.Hosting.Maui.Tests, Aspire.Hosting.Milvus.Tests (2 hops), Aspire.Hosting.MongoDB.Tests (2 hops), Aspire.Hosting.MySql.Tests (2 hops), Aspire.Hosting.Nats.Tests (2 hops), Aspire.Hosting.OpenAI.Tests (2 hops), Aspire.Hosting.Oracle.Tests (2 hops), Aspire.Hosting.Orleans.Tests (2 hops), Aspire.Hosting.PostgreSQL.Tests (2 hops), Aspire.Hosting.Python.Tests (2 hops), Aspire.Hosting.Qdrant.Tests (2 hops), Aspire.Hosting.RabbitMQ.Tests (2 hops), Aspire.Hosting.Redis.Tests (2 hops), Aspire.Hosting.RemoteHost.Tests, Aspire.Hosting.Seq.Tests (2 hops), Aspire.Hosting.SqlServer.Tests (2 hops), Aspire.Hosting.Testing.Tests (2 hops), Aspire.Hosting.Valkey.Tests (2 hops), Aspire.Hosting.Yarp.Tests (2 hops), Aspire.Playground.Tests

🔧 src/Shared/ConsoleLogs/LogEntry.cs (changed source)
→ 4 via the project graph: Aspire.Cli.Tests, Aspire.Dashboard.Components.Tests, Aspire.Dashboard.Tests, Aspire.Managed.Tests (2 hops)

📦 affected project Aspire.Cli
→ 1 test: Aspire.Cli.EndToEnd.Tests

📦 affected project Aspire.Hosting
→ 1 test: Aspire.EndToEnd.Tests

🧪 tests/Aspire.Hosting.Containers.Tests/ResourceFailureLoggingTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Containers.Tests

🧪 tests/Aspire.Hosting.Tests/Dcp/DcpExecutorTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

🧪 tests/Aspire.Hosting.Tests/Dcp/TestKubernetesService.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

🧪 tests/Aspire.Hosting.Tests/ResourceFailureLoggingTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

🧪 tests/Aspire.Hosting.Tests/ResourceLoggerServiceTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

Job reasons

Job	Triggered by
cli-starter	• affected project Aspire.Cli • selected test Aspire.Cli.Tests
deployment-e2e	affected project Aspire.Cli
extension-e2e	• src/Aspire.Hosting/ApplicationModel/ResourceLoggerService.cs, src/Aspire.Hosting/Dcp/DcpExecutor.cs, src/Aspire.Hosting/Dcp/DcpResourceWatcher.cs, src/Aspire.Hosting/ResourceLoggerForwarderService.cs • affected project Aspire.Hosting
polyglot	affected project Aspire.Cli
typescript-api-compat	affected project Aspire.Hosting

---

Selection computed for commit c83b92e.

[Copilot]

Review details

• Files reviewed: 10/10 changed files
• Comments generated: 0 new
• Review effort level: Medium

[aspire-repo-bot]

⚠️ Documentation was required for this change, but a docs PR could not be drafted automatically.

A docs PR was drafted on branch docs/flush-logs-before-terminal-notifications (targeting release/13.5) but the create_pull_request safe-output tool failed twice with ERR_SYSTEM: Git command failed with status 1 — the shallow clone (fetch-depth=1) prevents patch generation for the new commit 50eea5b.

Triggered signals: pr_body_has_user_facing_section (PR has a ### User-facing behavior section describing the log-flush guarantee) and pr_body_has_cli_flag_mention (false positive from build validation steps).

Intended change: added a new "Diagnose resource startup failures" section to src/frontend/src/content/docs/testing/advanced-scenarios.mdx explaining that DCP stdout/stderr is flushed to the host ILogger before WaitForResourceAsync resolves to FailedToStart/Exited. A maintainer can manually apply the committed change from branch docs/flush-logs-before-terminal-notifications in the microsoft/aspire.dev repository.

See the workflow run for details: https://github.com/microsoft/aspire/actions/runs/28404445919