dotnet
[browser] Wasm.Build.Tests timeout - Timed out after 10s waiting for 'WASM EXIT'
Build Information
Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=1068222 Build error leg or test failing: NoWebcil-ST-Wasm.Build.Tests.MainWithArgsTests.WorkItemExecution Pull request: https://github.com/dotnet/runtime/pull/116639
Error Message
Fill the error message using step by step known issues guidance.
{
"ErrorMessage": "Timed out after 10s waiting for 'WASM EXIT' messag",
"ErrorPattern": "",
"BuildRetry": true,
"ExcludeConsoleLog": false
}
Known issue validation
Build: :mag_right: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1068222
Error message validated: [Timed out after 10s waiting for 'WASM EXIT' messag]
Result validation: :x: Known issue did not match with the provided build.
Validation performed at: 6/16/2025 4:06:50 PM UTC
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 1 | 2 | 10 |
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 2 | 9 |
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 11 | 47 |
@dotnet/dnceng BA is not matching the error, presumably because is not in the console log? It's in xharness-output\testResults.xml.
Duplicate of https://github.com/dotnet/runtime/issues/113836 but for a different test.
@dotnet/dnceng BA is not matching the error, presumably because is not in the console log? It's in xharness-output\testResults.xml.
@jozkee this documentations says where Known Issues can look at error information: https://github.com/dotnet/arcade/blob/main/Documentation/Projects/Build%20Analysis/KnownIssues.md#how-the-matching-process-works-between-a-known-issue-and-a-buildtest-error
@missymessa looks to me xharness-output\testResults.xml is a helix log. I also set "ExcludeConsoleLog": true, assuming that gives more range in case the 100 logs limit was being reached.
But looks like BA gave up on this issue.
@jozkee I can open an issue to investigate this. Are you currently blocked on this?
@jozkee this is too broad of a pattern to be useful. It will catch any timeout even newly introduced ones.
@lewing I just broadened it because I saw LoadLazyAssemblyBeforeItIsNeeded (https://github.com/dotnet/runtime/issues/113836) existed and I got https://github.com/dotnet/runtime/issues/113836#issuecomment-2977135992 I suspected more tests would fail and wouldn't be great to have one issue per each failing test. Feel free to adjust it.
KnownBuildErrors that can easily hide new regressions are actively harmful by making what should be failing CI look green. It is always a balance but blanket matches against a timeout are generally too broad.
Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.
![dotnet-policy-service[bot] avatar](https://avatars.githubusercontent.com/in/285228?v=4 "Published by a pub.dev verified publisher"){kind=small}
removing blocking-clean-ci as it has not failed in 30 days
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 0 | 0 |
