Fix sync ConnectHelper.Connect #40880
Conversation
|
Tagging subscribers to this area: @dotnet/ncl |
| @@ -62,6 +62,9 @@ public static Connection Connect(string host, int port, CancellationToken cancel | |||
| { | |||
| socket.Connect(new DnsEndPoint(host, port)); | |||
| } | |||
|
|
|||
| // Since we only do GracefulShutdown in SocketsHttpHandler code, Connection.FromStream() should match SocketConnection's behavior: | |||
| return Connection.FromStream(new NetworkStream(socket, ownsSocket: true), localEndPoint: socket.LocalEndPoint, remoteEndPoint: socket.RemoteEndPoint); | |||
There was a problem hiding this comment.
The key here is to have NetworkStream ctor inside the try block. If having Connection.FromStream inside it as well is not desired, this can be split into 2 lines.
|
@ManickaP thanks a lot for dealing with this. I think neither my nor @scalablecory 's PR respected this scenario. Wouldn't it make sense to add a regression test for it? (I mean something less fragile than the HttpWebRequest test that used to fail occasionally.) |
|
I don't how would you design such test. The error manifested only if cancellation happened exactly between socket creation and |
|
This is an improvement from what it did previously, but isn't it still going to result in ObjectDisposedException? That seems bad. |
|
If the dispose is a result of cancellation (which was the case here) then it won't since it gets mapped to |
|
That makes sense, thanks. I still think it's a bit odd that the OperationCancelledException will end up with an inner error of ObjectDisposedException, but I guess that's what we do today anyway. |
ghost
locked as resolved and limited conversation to collaborators
Redo of #39514
Fixes #40876
Fixed #40881