-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wasm] SendReceive_VaryingLengthBuffers_Success failing in CI #53957
Comments
Tagging subscribers to this area: @dotnet/ncl Issue Details
Configuration: Build Browser wasm Release AllSubsets_Mono
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
Configuration: Build Browser wasm Release AllSubsets_Mono
|
Not sure what is going on here @pavelsavara can you take a look? |
Note: There is also bunch of similar failures of this test, but perhaps that has been already addressed?
Data from 4/18-6/17 (incl. PRs) -- Mono failures all, mostly wasm:
|
error |
Running this locally in tight loop I was able to only reproduce
|
With timeout down to 3000ms
|
I'm seeing this again in #55899, which includes the fix from #54453.
|
cc @kg Pavel is out of office this week. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
It started failing after it was re-enabled on 7/15 in PR #54453:
I think the test needs to be disabled again ... Alternative failure "WebSocketException":
|
Disable failing test #56293 |
I'm able to reproduce it locally if I decrease timeout or run the body of the test in a loop many times. So, now I think that it's a consequence of timeout. But the timeout is 30s for a test here, so I'm not clear if the CI machine could be so slow. |
And also in CI
|
Is there a way for us to identify whether a timeout happened deeper in the stack (i.e. a browser quirk or issue with the server) vs inside our code? I feel like it's possible the intermittent failures here aren't our fault and could be due to something about how we're running these tests, but we'd need some way to verify that. |
WASM network tests are running with echo server inside xharness process, which is different process on the same machine. For part of HTTP tests, we are talking directly to the xharness kestrel. For the Loopback part of the tests, we are unable to implement loopback directly on the WASM and therefore we use WebSockets to control the remote loop on the xharness process. On top of that we have extra layer of browser networking stack. Also, our WS implementation has extra layer of buffering between WASM and browser. #44614 I will try to run |
@pavelsavara, did you get any more details when running |
not really, but maybe this could be related to the issue we found with @maraf yesterday ? |
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-53905-merge-5a8d9815e63046a192/System.Net.WebSockets.Client.Tests/console.608b53e4.log?sv=2019-07-07&se=2021-06-29T19%3A48%3A07Z&sr=c&sp=rl&sig=pEysk8NCg3vGVdQFHK7K1Q12bdrdQ83pA6K9hLXcrb0%3D
Build: https://dev.azure.com/dnceng/public/_build/results?buildId=1179573&view=logs&j=108d2c4a-8a62-5a58-8dad-8e1042acc93c&t=568f884b-cc12-5fd3-e7fe-790b5ac403f4
Configuration: Build Browser wasm Release AllSubsets_Mono
The text was updated successfully, but these errors were encountered: