Description
Console log: 'System.Threading.Overlapped.Tests' from job 3b35b4cb-4e38-4976-af50-781bfa993c05 workitem 323d7522-2635-4b16-91cc-5b49cdf6e797 (windows.7.amd64.open.rt) executed on machine a000KGO
ThreadPoolBoundHandleTests.MultipleOperationsOverSingleHandle_CompletedWorkItemCountTest [FAIL]
Assert.InRange() Failure
Range: (0 - 30000)
Actual: 30015
Stack Trace:
/_/src/libraries/Common/tests/System/Threading/ThreadTestHelpers.cs(147,0): at System.Threading.Tests.ThreadTestHelpers.WaitForConditionWithCustomDelay(Func`1 condition, Action delay)
/_/src/libraries/Common/tests/System/Threading/ThreadTestHelpers.cs(117,0): at System.Threading.Tests.ThreadTestHelpers.WaitForCondition(Func`1 condition)
/_/src/libraries/System.Threading.Overlapped/tests/ThreadPoolBoundHandle_IntegrationTests.netcoreapp.cs(16,0): at ThreadPoolBoundHandleTests.MultipleOperationsOverSingleHandle_CompletedWorkItemCountTest()
Finished: System.Threading.Overlapped.Tests
Looking at the test, it waits on some async IO to complete (so IO delay is not the issue as it's completed) and then waits up to 30 seconds, checking every 1 ms for ThreadPool.CompletedWorkItemCount to grow to a value at least 2 larger than before the IO happened.
I did at first think that the use of Environment.TickCount here might be fragile, as it will wrap every ~month the computer has been running, but that would still produce the correct value unless the interval was comparable with that period of time.
https://github.com/dotnet/runtimelab/blob/43f8f4f66ea6c7216d5a60d44df3ff4713863279/src/libraries/Common/tests/System/Threading/ThreadTestHelpers.cs#L147
Helix didn't seem to register this in Kusto as a failure, so I can't query failure history, but Azdo does, and it shows one other recent failure, a few hours apart.
Console log: 'System.Threading.Overlapped.Tests' from job 0e164bfa-2125-453f-b408-b425e865cd01 (windows.10.amd64.server20h1.open.rt) using docker image mcr.microsoft.com/dotnet-buildtools/prereqs:windowsservercore-2004-helix-amd64-20200904200251-272704c on a000Z2T
For what it's worth, a000KGO seems to have been rebooted shortly before running the test, although as mentioned, I do'nt think TickCount wrap is relevant.
@kouvel ?