Repository navigation
Fix flaky ExecuteCommandAsync_RebuildCommand_ReturnsBuildOutput build count - #21427
Conversation
The project resource is launched with `dotnet run`, which also builds it. When the rebuild command restarts the project and the next rebuild cannot stop that process before its build finishes (common on Windows), the shared build-count file gets an extra entry and the test sees 3 builds instead of 2. Tag the hidden rebuilder's `dotnet build` with an environment variable and only count builds that carry it, so the assertion measures exactly the builds performed by the rebuild command. Fixes #20662 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 21427Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 21427" |
github-actions
Bot
added
the
area-engineering-systems
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues are reported for the test-only change that isolates rebuild-command build counting.
No open issues 🎉
What changed in this PR
Addresses the flaky rebuild-command test in #20662 by excluding builds triggered by dotnet run from its build counter. Changes are limited to tests; product behavior is unchanged.
Changes:
- Tags the hidden rebuilder resource with a test-only environment variable.
- Counts builds only when that variable is set.
- Asserts exactly one build after the first rebuild command and two after the second.
| File | Description |
|---|---|
tests/Aspire.Hosting.Tests/ResourceCommandServiceTests.cs |
Isolates rebuild-command build counting and tightens assertions to avoid the Windows timing race. |
Review effort: Balanced
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
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. |
|
New occurrence on an unrelated PR: #21461 run 41076125682, Hosting-2 (windows-latest), attempt 1, at
🤖 Posted by AspireAgent (AI Agent) |
# Conflicts: # tests/Aspire.Hosting.Tests/ResourceCommandServiceTests.cs
Tests selector6 / 100 PR test projects · 0 PR jobs, from 1 changed file. Selected PR test projects (6 / 100)
Selected PR jobs (0)none How these were chosen — grouped by what changed🧪 Job reasonsnone Selection computed for commit |
James Newton-King (JamesNK)
left a comment
James Newton-King (JamesNK)
left a comment
There was a problem hiding this comment.
No issues found. Reviewed rebuilder environment isolation, conditional build counting, and sequential rebuild completion. The changed ExecuteCommandAsync_RebuildCommand_ReturnsBuildOutput regression test passed 3/3 local Windows runs with MTP-native filtering and quarantined/outerloop tests excluded.
|
✅ No documentation update needed. docs_optional → test_only. The only changed file is |
Description
Fixes the intermittent
ExecuteCommandAsync_RebuildCommand_ReturnsBuildOutputfailure (Assert.Equal() Failure: Expected: 2, Actual: 3) onHosting-2 (windows-latest).Root cause. The test project appends to
build-count.txtfrom anAfterTargets="Build"target and the test asserts that the second rebuild command adds exactly one line. But the project resource itself is launched withdotnet run(no--no-build), which also builds it. After the first rebuild restarts the project, the second rebuild has to stop thatdotnet runprocess. On Windows the stop often takes several seconds (Executable ... is still running; trying again to stop it...), so the restarteddotnet runfinishes its own build and writes an extra line. The test then sees 3 lines instead of 2. The native TRX output from run 39366740926 shows this sequence: a 6-second stop window between the restart and the second rebuild.Fix. The hidden
myProject-rebuilderresource gets anASPIRE_TEST_REBUILD_COMMAND_BUILD=trueenvironment variable, and the counting target only runs when that variable is set. Only builds started by the rebuild command are counted. The assertions are stricter than before: exactly 1 after the first rebuild and exactly 2 after the second. No product code changes.Verification (local, Linux, repo SDK).
dotnet runto exit 0 before the second rebuild. With the original counting it failed 3/3 withExpected: 2, Actual: 3(one run: 2→4). With the new counting it passed 3/3.ExecuteCommandAsync_RebuildCommand_ReturnsBuildOutputpassed 5/5 runs.Recurrence. On main CI between 2026-10-13 and 2026-10-30, 14
Hosting-2 (windows-latest)jobs failed out of about 120 sampled. 10 of those failures had TRX artifacts, and this test was the only failure in all 10. The other 4 had no artifacts. The most recent failure was on 2026-10-30 (run 40992075134).Fixes #20662
Checklist
🤖 Posted by AspireAgent (AI Agent)