-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Improve reliability of HttpRequestError.NameResolutionError #89948
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
Conversation
|
Tagging subscribers to this area: @dotnet/ncl |
| IgnoreScopeIdIPEndpointComparer endPointComparer = new(); | ||
| Assert.Equal(listener.LocalEndPoint, serverConnection.LocalEndPoint, endPointComparer); | ||
| Assert.Equal(listener.LocalEndPoint, clientConnection.RemoteEndPoint, endPointComparer); | ||
| Assert.Equal(clientConnection.LocalEndPoint, serverConnection.RemoteEndPoint, endPointComparer); |
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.
To improve confidence in my changes, I extended this test to test IPv6. serverConnection.LocalEndPoint has a ScopeId for some reason while listener.LocalEndpoint doesn't. I assume it is asigned after binding, and we can ignore this difference.
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.
scopeID should be only relevant for LLA. I'm wondering if we are deviating from Socket/NetworkStream here because the underlying MSQuic implementation.
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.
It's possible. If we think it's a problem we can track it in a separate issue.
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.
It seems like this was existing condition. We miss it because QuicConnectionTests.TestConnect only tests IPv4. I sync back and I tried it with IPv6 and it also fails:
Starting: System.Net.Quic.Functional.Tests (parallel test collections = on, max threads = 4)
System.Net.Quic.Tests.QuicConnectionTests.TestConnect [STARTING]
System.Net.Quic.Tests.QuicConnectionTests.TestConnect [FAIL]
Assert.Equal() Failure
Expected: [::1]:34850
Actual: [::1%1]:34850
I will fix it tomorrow.
(cc: @ManickaP)
src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/ConnectHelper.cs
Show resolved
Hide resolved
| if (exception is SocketException socketException && | ||
| socketException.SocketErrorCode is SocketError.HostNotFound or SocketError.TryAgain) |
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.
If you wanted to, since you're already using pattern matching, you could make this even more concise:
exception is SocketException { SocketErrorCode: SocketError.HostNotFound or SocketError.TryAgain }|
Failures were unrelated in System.Text.Encoding.Tests on Ubuntu 18.04, rerunning them.
|
wfurt
left a comment
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
Fixes #89095
Fixes #89096
Applies the heuristic solutions we agreed on.