-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
SignedXmlTest.VerifyXmlResolver sometimes failing due to failing to connect to localhost. #74115
Comments
Tagging subscribers to this area: @dotnet/area-system-xml Issue DetailsThis was just introduced in #73676 and is failing at least 4 times a day. @GrabYourPitchforks HttpListener was successfully started on 127.0.0.1:9000, but apparently did not respond promptly. Looking at history, we also see failures on Android, Ubuntu, which may have a slightly different error:
|
Since this test was just added and it's failing often, I'd like to see the test fix get addressed in the release/7.0 branch to prevent permanent noise there. |
Slightly unrelated to the test failure itself -- shouldn't this test be part of outerloop? |
Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones Issue DetailsThis was just introduced in #73676 and is failing at least 4 times a day. @GrabYourPitchforks
HttpListener was successfully started on 127.0.0.1:9000, but apparently did not respond promptly. That was on Windows. Looking at history, we also see failures on Android and Ubuntu, which may have a slightly different error:
It's probably significant that this is not OS specific. @dotnet/ncl do you see anything obvious about the test here? Code:
|
That's probably reasonable. It seems odd that there's enough load going on that these tests can't reliably use HttpListner / loopback networking... but c'est la vie. |
My suggestion would be to re-write the test. |
@bartonjs Maybe we can use a static file on disk rather than an http listener? I remember when we discussed this a few months ago during the original CVE fix the issue of test flakiness was brought up, but at the time it was deemed that this would be stable enough for innerloop use. Do we know what was wrong with our analysis? |
Nope. The X509 revocation tests and AIA tests all use HttpListener, and while there is an occasional problem they don't fail all that often. Of course, they're all OuterLoop, not because of the HttpListener, but because they take several minutes to run. So maybe it's just that innerloop runs so much more often that it's showing up here. |
If we disable this have we lost protection against regressing the security feature? |
We're discussing in email some other ways of making a less flaky test. Those other mechanisms would give us varying degrees of confidence that we didn't regress this. |
@bartonjs and @GrabYourPitchforks reported progress on these discussions and work is underway to refactor the tests. While this isn't blocking the release, we will want to get the text changes into the release/7.0 branch so that we have regression protection there for servicing. |
@bartonjs looks like your PR didn't fix the test yet. Re-disabling it again in PR #76129 Failures in last 30 days
|
Test disabled in PR #76129 -- it can be probably narrowed down to the specific platform, or fixed for the platform. |
I think the problem here is that the listener doesn't start by the time we send request. I think the order should be following: testcase:
task:
possibly can be simplified by maybe doing everything until |
This was just introduced in #73676 and is failing at least 4 times a day. @GrabYourPitchforks
History: https://dev.azure.com/dnceng/public/_build/results?buildId=1949830&view=ms.vss-test-web.build-test-results-tab&runId=50186248&resultId=193531&paneView=history
example https://dev.azure.com/dnceng/public/_build/results?buildId=1949830&view=ms.vss-test-web.build-test-results-tab&runId=50186248&resultId=193531&paneView=debug
HttpListener was successfully started on 127.0.0.1:9000, but apparently did not respond promptly. That was on Windows. Looking at history, we also see failures on Android and Ubuntu, which may have a slightly different error:
It's probably significant that this is not OS specific. @dotnet/ncl do you see anything obvious about the test here? Code:
runtime/src/libraries/System.Security.Cryptography.Xml/tests/SignedXmlTest.cs
Line 1603 in f140a12
Report
Summary
The text was updated successfully, but these errors were encountered: