search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.64k stars 4.57k forks source link

System.IO.Tests.File_ReadWriteAllBytes.ReadAllBytes_NonSeekableFileStream_InWindows failed #60427

Open runfoapp[bot] opened 2 years ago

runfoapp[bot] commented 2 years ago
Runfo Tracking Issue: System.IO.Tests.File_ReadWriteAllBytes.ReadAllBytes_NonSeekableFileStream_InWindows failed Build Definition Kind Run Name
Build Result Summary Day Hit Count Week Hit Count Month Hit Count
0 0 0
ghost commented 2 years ago

Tagging subscribers to this area: @dotnet/area-system-io See info in area-owners.md if you want to be subscribed.

Issue Details
Runfo Creating Tracking Issue (data being generated)
Author: runfoapp[bot]
Assignees: -
Labels: `area-System.IO`, `untriaged`
Milestone: -
safern commented 2 years ago

I couldn't find an existing issue for this test and just hit it on: https://github.com/dotnet/runtime/pull/60415

cc: @krwq

ericstj commented 2 years ago

Looks like this test was just added in https://github.com/dotnet/runtime/pull/58434 and is failing in many PRs. @lateapexearlyspeed @adamsitnik

lateapexearlyspeed commented 2 years ago

Hi @ericstj Sorry about that. Hi @adamsitnik seems this WaitForConnectionAsync() in test case takes long time sometimes. I just run this test in my local pc to verify that time-consuming call. And eventually it can return back if remove cancellation token source. Current master code cancels cts after waiting for 50 second. Not sure if we should remove cts (like what we did for unix version test.) ?

ericstj commented 2 years ago

No worries, this happens a lot with tests that have open ended timeouts like this. The scale we run dotnet/runtime tests + load on the machine can cause things to take a lot longer than you'd think possible.

ericstj commented 2 years ago

Reopening to track the disabled test.