Fix flakyness of DnsGetHostAddresses_PostCancelledToken_Throws#70044
Conversation
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsIgnore cases when the call returns (throws/fails) before we manage to cancel it. Fixes #69993.
|
| if (ex is OperationCanceledException oce) | ||
| { |
There was a problem hiding this comment.
I'm a bit late to the party, but the test will now no longer fail if the implementation lacks actual cancellation support, so it became mostly useless.
In theory, [Collection(nameof(DisableParallelization))] was here to somewhat mitigate the race. I wonder if there is something specific about the OS-es/machines/queues where this is failing?
I see Ubuntu failures in kusto, which doesn't make sense to me, since the test is marked with [ActiveIssue(***, TestPlatforms.AnyUnix)] which AFAIK should disable the test on Linux.
There was a problem hiding this comment.
I have re-enabled the tests in #70009, since the issue mentioned was already closed (and the feature presumably implemented)
There was a problem hiding this comment.
I wonder if there is something specific about the OS-es/machines/queues where this is failing?
It is failing in jitstress, which may increase the chance of the cancelling thread losing the race.
There was a problem hiding this comment.
but the test will now no longer fail if the implementation lacks actual cancellation support, so it became mostly useless.
I have missed that :/, do you have any suggestions how to bring it back without the flakyness?
There was a problem hiding this comment.
It is failing in jitstress, which may increase the chance of the cancelling thread losing the race.
Is there a way to detect if we are in a jitstress run, and skip the test in those cases only? It feels to me like jitstress is fundamentally incompatible with timing-critical networking tests, which we have many in fact.
I have re-enabled the tests in #70009, since the issue mentioned was already closed (and the feature presumably implemented)
#34633 has been reverted, there is still no async name resolution and cancellation support on Linux.
There was a problem hiding this comment.
Hmm, I have fallen to another trap... I will revert that PR then.
We should be able to detect jitstress by looking at envvars, I will take a look
There was a problem hiding this comment.
It was super-confusing. We may consider reopening #33378, but it's very unlikely that we'll address in the near future, so probably it's better to just skip the test on Unix with [PlatformSpecific] + a comment.
dotnet#70044)" This reverts commit a466063.
Ignore cases when the call returns (throws/fails) before we manage to cancel it.
Fixes #69993.