[docs] Note that resource logs flush before terminal notifications - #1435
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
David Pine (IEvangelist)
left a comment
There was a problem hiding this comment.
Validated against microsoft/aspire#18539. The new tip accurately documents the log-flush ordering guarantee for terminal resource notifications.
There was a problem hiding this comment.
Pull request overview
This PR updates the testing documentation to describe the ordering guarantee around forwarding resource stdout/stderr logs relative to publishing terminal resource-state notifications, so WaitForResourceAsync-based tests can surface diagnostic output for fast-failing resources.
Changes:
- Adds a tip callout under “Ensure resources are available” explaining that resource logs are flushed before terminal (
Exited/FailedToStart) notifications are published.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| If a resource fails during startup (for example, a container exits | ||
| immediately or an executable can't be found), Aspire flushes any captured | ||
| resource logs before it publishes the terminal (`Exited` or `FailedToStart`) | ||
| state notification. That means test code awaiting `WaitForResourceAsync` | ||
| with a terminal state can rely on the resource's stdout/stderr output being | ||
| present in the captured host logs at the point the wait completes, which | ||
| makes fast-failing resources easier to diagnose. |
Frontend HTML artifact readyThe latest frontend build uploaded the This comment updates automatically when a new frontend build artifact is uploaded. |
Documents changes from microsoft/aspire#18539
@davidfowlTargeting
release/13.5based on the source PR milestone13.5.Why
The source PR flushes captured DCP stdout/stderr logs to resource-log subscribers before publishing terminal (
Exited/FailedToStart) resource-state notifications. Previously, fast-failing containers/executables could reach a terminal state before their logs were forwarded, makingDistributedApplicationTestingBuilder-based test failures hard to diagnose becauseWaitForResourceAsynccould return before the relevant logs were visible.The existing
testing/accessing-resources.mdxpage documentsWaitForResourceAsyncbut did not mention this log-flush guarantee, which is directly relevant to test authors diagnosing resource failures.What changed
src/frontend/src/content/docs/testing/accessing-resources.mdxunder "Ensure resources are available", explaining that resource stdout/stderr logs are flushed before terminal state notifications are published, so test code awaitingWaitForResourceAsyncwith a terminal state can rely on that output being present in captured host logs.Files changed
src/frontend/src/content/docs/testing/accessing-resources.mdx(updated)