Failing test due to no detected IO events in 'System.IO.Tests.FileSystemWatcherTest.ExecuteAndVerifyEvents'

[Sergio0694]

Build Information

Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=709665
Build error leg or test failing: System.IO.Tests.Directory_Delete_Tests.FileSystemWatcher_Directory_Delete_SymLink
Pull request: #103528

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "Deleted event did not occur as expected",
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=709665
Error message validated: [Deleted event did not occur as expected]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 6/17/2024 3:57:06 PM UTC

Report

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	0

[jozkee]

This is just FileSystemWatcher being flaky in Windows as always... We may try to add more retries and see if that makes it less noisy.

[jakobbotsch]

@jozkee Can you disable the test until the flakiness is resolved? This is marked blocking-clean-ci so I don't think putting it in a 10.0 milestone is appropriate.

[jozkee]

What makes an issue be tagged as blocking-clean-ci? i.e. how many times does it have to fail for it to not be blocking-clean-ci-optional?

[jozkee]

I'm hesitant on disabling the tests because they are multiple methods, I would have to disable the whole class which seems risky.

[jakobbotsch]

blocking-clean-ci = it is failing in the default pipelines that run on all PRs. blocking-clean-ci-optional = it is failing in non-default pipelines (like libraries-jitstress).

In both cases the failures are disruptive to a lot of people and should be made non-blocking asap, either by resolving the underlying problems, disabling the tests (with expected future investigation), or removing the tests.

I'm hesitant on disabling the tests because they are multiple methods, I would have to disable the whole class which seems risky.

If these tests are flaky isn't that flakiness just going to mask any real failures, making the test not very useful?

[danmoseley]

In the past I've fixed other FSW tests by adding more retries (or firing more events). Retries are easy to add and they should be outer loop if not already.