Skip to content

Stabilize flaky dotnet-watch tests (DeleteSubfolder, ServerAndResources)#54955

Open
dsplaisted wants to merge 1 commit into
dotnet:mainfrom
dsplaisted:fix-watch-test-flakiness
Open

Stabilize flaky dotnet-watch tests (DeleteSubfolder, ServerAndResources)#54955
dsplaisted wants to merge 1 commit into
dotnet:mainfrom
dsplaisted:fix-watch-test-flakiness

Conversation

@dsplaisted

Copy link
Copy Markdown
Member

Summary

Attempt to fix two flaky dotnet-watch tests. This is based on copilot's analysis of failures seen in #54945. One of them also failed on an unrelated PR. Pipelines:

Copilot's descriptions below:

FileWatcherTests.DeleteSubfolder

On macOS the file-system event replay intermittently includes a directory-level subdir Add event. Because the test stops collecting once it has seen the expected number of events, that spurious event displaces one of the expected file events and the assertion fails. Restrict the watcher to the watched file names (foo1/foo2/foo3) so the directory event is filtered out by the watcher's existing name filter. Harmless on other platforms.

AspireLauncherIntegrationTests.ServerAndResources

Status events are delivered over a separate pipe from the server's output. The test cancelled the status reader based on the server output, which races with status delivery and occasionally dropped the restart's process_started event. ReadStatusEventsAsync now reads until the expected number of status events has been received instead of relying on output-based cancellation.

Related: #53061 (the existing macOS tracking issue for this test; the [OSCondition(Exclude)] is left in place for the watch team to re-evaluate).

Notes

These touch nondeterministic file-watcher / launcher tests, so they're proposed for watch-team review.

…rces

These two tests fail intermittently under CI; both are timing/ordering races rather
than product bugs.

FileWatcherTests.DeleteSubfolder: on macOS the file-system event replay intermittently
includes a directory-level 'subdir' Add event. Because the test stops collecting once it
has seen the expected number of events, that spurious event displaces one of the expected
file events and the assertion fails. Restrict the watcher to the watched file names so the
directory event is filtered out.

AspireLauncherIntegrationTests.ServerAndResources: the status events are delivered over a
separate pipe from the server's output, and the test cancelled the status reader based on
the output, which races with status delivery and occasionally dropped the restart's
process_started event. Read until the expected number of status events has been received
instead of cancelling on output. Related: dotnet#53061.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings June 24, 2026 01:03
@dsplaisted dsplaisted requested review from a team and tmat as code owners June 24, 2026 01:03

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR aims to reduce flakiness in dotnet-watch test coverage by making two tests less sensitive to nondeterministic event delivery (file-system event replay on macOS and status-event timing over named pipes).

Changes:

  • Stabilize FileWatcherTests.DeleteSubfolder by restricting watched file names to exclude spurious directory-level events on macOS.
  • Make Aspire status-pipe reading deterministic by reading until an expected event count is reached (instead of canceling based on server output timing).
  • Refactor AspireLauncherIntegrationTests.ServerAndResources to define expected status events once and reuse them for both reading and assertion.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
test/dotnet-watch.Tests/FileWatcher/FileWatcherTests.cs Filters watched file names in DeleteSubfolder to avoid intermittent directory add events displacing expected file events.
test/dotnet-watch.Tests/Aspire/PipeUtilities.cs Updates status-event reader to stop after a specified expected number of events (or cancellation).
test/dotnet-watch.Tests/Aspire/AspireLauncherIntegrationTests.cs Removes output-driven cancellation and drives status reading by expected event count; reuses expected event list for assertion.

Comment on lines 189 to +191
AssertEx.SequenceEqual(
[
$"type=build_complete, projects=[{serviceProjectA};{serviceProjectB}]",
$"type=building, projects=[{serviceProjectA};{serviceProjectB}]",
$"type=hot_reload_applied, projects=[{serviceProjectA};{serviceProjectB}]",
$"type=process_started, projects=[{serviceProjectA}]",
$"type=process_started, projects=[{serviceProjectA}]",
$"type=process_started, projects=[{serviceProjectB}]",
$"type=restarting, projects=[{serviceProjectA}]",
], statusEvents.Select(e => $"type={e.Type}, projects=[{string.Join(";", e.Projects.Order())}]").Order());
expectedStatusEvents,
statusEvents.Select(e => $"type={e.Type}, projects=[{string.Join(";", e.Projects.Order())}]").Order());
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants