-
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
[QUIC] Disable QUIC tests on CLR stress tests #96392
[QUIC] Disable QUIC tests on CLR stress tests #96392
Conversation
Tagging subscribers to this area: @dotnet/ncl Issue DetailsFixes #86565 I'm not sure about disabling the tests completely on Arm32, any opinions @wfurt @rzikm @CarnaViire
|
@@ -10,6 +10,7 @@ namespace System.Net.Quic.Tests | |||
{ | |||
[Collection(nameof(DisableParallelization))] | |||
[ConditionalClass(typeof(QuicTestBase), nameof(QuicTestBase.IsSupported))] | |||
[SkipOnCoreClr("MsQuic is timing sensitive and flaky under stress", ~RuntimeTestModes.RegularRun)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no way to make the tests resilient against timing issues? What specifically is the problem that leads to the flakiness?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We suspect #55979 as root cause. There is logic in MsQuic to watch load and start refusing connection if CPU utilization is too high. For normal tests runs we disabled parallel runs to avoid it but the stress may be still be too much.
To start with, we may disable stress only on ARM. It seems like it failed on ARM64 as well but it is hard to tell much as most of the links leads to nowhere now ;(
I did a bit digging in Kusto:
Query:
|
Thanks @ManickaP.
I wonder if that was #91757 (it was mitigated around Nov 13) I think we should disable QUIC tests on jitstress runs on Arm32 and Arm64 (because Arm64 was also reported there) but keep them for other platforms. I'd vote for not disabling Arm32 completely yet, if we don't see failures in our normal runs since Nov 13... |
So I don't know how to combine Is there an easier way @ViktorHofer, @akoeplinger, @BruceForstall? Is this even worth the effort @wfurt @rzikm @CarnaViire? |
Interestingly, there are no such records in Kusto. |
I'm certainly no expert in libraries test exclusions, but I do believe there is no "AND" functionality, as you've found. |
btw, thank you for working on this! |
there may be other occasional failures on other platforms. I think it would be OK to exclude arm32 since that is was majority and wait. We may need to create new static variable for the condition - especially if we want to be more selective. |
/azp list |
/azp run runtime-coreclr libraries-jitstress |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run runtime-coreclr libraries-pgo |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
You don't need to copy the logic since |
Fixes #86565
I'm not sure about disabling the tests completely on Arm32, any opinions @wfurt @rzikm @CarnaViire