[MT][browser] Disable new CI failures on library MT tests

[ilonatommy]

• Block Wasm.Browser.Threads.Minimal.Sample.csproj for MT

• Move issues connected with MT exclusions to be blocked only in MT mode.

• Add project exclusion for Microsoft.Extensions.DependencyInjection.Tests

• Fixing fail: [out of order message from the browser]: http://127.0.0.1:33323/_framework/dotnet.js 2 WebSocket connection to 'ws://127.0.0.1:33323/_framework/dotnet.native.worker.js/console' failed: Error during WebSocket handshake: Unexpected response code: 404

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

• We were planning to switch off shouldContinueOnError after a few weeks from merging [browser][MT] enable all MT library tests on the runtime CI pipeline #91536 if it will not be failing after disabling.
• Fixing fail: [out of order message from the browser]: http://127.0.0.1:33323/_framework/dotnet.js 2 WebSocket connection to 'ws://127.0.0.1:33323/_framework/dotnet.native.worker.js/console' failed: Error during WebSocket handshake: Unexpected response code: 404 log

Author:	ilonatommy
Assignees:	-
Labels:	arch-wasm, area-VM-threading-mono
Milestone:	-

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

How often has this run recently, and how often has it failed?

[pavelsavara]

How often has this run recently, and how often has it failed?

It failed "silently" for me. I have not noticed that there is "organge" lane. I want it to really fail when I do /azp run runtime-wasm

[radical]

'runtime-wasm' will be red then.

[pavelsavara]

'runtime-wasm' will be red then.

Right, that's what we want to anything that was not already marked active issue by Ilona in #91536.

Am I missing something ?

[ilonatommy]

This PR needs adding a blocking for Wasm.Browser.Threads.Minimal.Sample and Microsoft.Extensions.DependencyInjection.Tests, they might have been overlooked in the big blocking PR (I will add it). Beyond that, nothing else failed. If a new failure will arise, we will at least notice it thanks to this change.

[radical]

'runtime-wasm' will be red then.

Right, that's what we want to anything that was not already marked active issue by Ilona in #91536.

Am I missing something ?

Has the job been green for few weeks when there were no PR introduced mt failures? That's what I'm talking about. It shouldn't randomly fail, else we would start getting merges on red and failures getting ignored because users aren't sure whether the failures are expected. A red pipeline on PRs that did not introduce mt failures would be counterproductive.

[radical]

This PR needs adding a blocking for Wasm.Browser.Threads.Minimal.Sample and Microsoft.Extensions.DependencyInjection.Tests, they might have been overlooked in the big blocking PR (I will add it). Beyond that, nothing else failed. If a new failure will arise, we will at least notice it thanks to this change.

Then it hasn't been green/stable for few weeks.

[ilonatommy]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

Please don't merge this yet. We should have couple of weeks worth of builds where the job has been green, before we merge.

[ilonatommy]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

Please don't merge this yet. We should have couple of weeks worth of builds where the job has been green, before we merge.

In that case we need to make the test run much more often. What we have now is useless waiting without any observability. Do you have any proposal @radical ?

[radical]

Please don't merge this yet. We should have couple of weeks worth of builds where the job has been green, before we merge.

In that case we need to make the test run much more often. What we have now is useless waiting without any observability. Do you have any proposal @radical ?

The test failures are observable, just that they won't show up as failures in github. Open the azdo build and you can see the failures, and all the details.

[ilonatommy]

Let's merge at least these fixes for now. Failures are unrelated.

[radical]

Let's merge at least these fixes for now.

👍 Please update the PR title, and description to match.

[radical]

Also, please open an issue for the error that is unrelated, and isn't being flagged by build analysis.