[QUIC&H/3] QuicConnection handshake timeout

[ManickaP]

Increased QuicConnection handshake timeout in tests.

Optional: propagated SocketsHttpHandler.ConnectTimeout to QuicConnectionOptions.HandshakeTimeout. Note that since the default is "infinite", this might lead to hanging connection establishment. So if there are any concerns, I'll revert this part of the change.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[liveans]

Optional: propagated SocketsHttpHandler.ConnectTimeout to QuicConnectionOptions.HandshakeTimeout. Note that since the default is "infinite", this might lead to hanging connection establishment. So if there are any concerns, I'll revert this part of the change.

I think this should be fine, because in the end HttpClient will fall back to the original Timeout.

[MihaZupan]

Setting the timeout to match SocketsHttpHandler.ConnectTimeout should be functionally the same as disabling it outright as the ConnectTimeout already controls the cancellation token passed to Quic.

Given that we don't have a default ConnectTimeout so far, I would actually prefer that we keep the current handshake timeout of 10 seconds (seems like plenty of time), unless it's been showing up as problematic?

[ManickaP]

because in the end HttpClient will fall back to the original Timeout.

What original timeout?

[ManickaP]

Given that we don't have a default ConnectTimeout so far, I would actually prefer that we keep the current handshake timeout of 10 seconds (seems like plenty of time), unless it's been showing up as problematic?

Some tests in CI are timing out on HandshakeTimeout. Before this PR, there's no way to change the default 10 seconds through HttpClient. But I do concur that 10s should be enough in all cases, for some reason it isn't. @liveans can you share the logs, kusto query, etc about the failing tests on handshake timeout?

[liveans]

because in the end HttpClient will fall back to the original Timeout.

What original timeout?

What I meant was HttpClient.Timeout property

[ManickaP]

because in the end HttpClient will fall back to the original Timeout.

What original timeout?

What I meant was HttpClient.Timeout property

That doesn't apply to connection creation. Also not present when using message invoker directly.

[MihaZupan]

Nit: this could just be Timeout.InfiniteTimeSpan

The cancellationToken passed to ConnectAsync is already backed by ConnectTimeout. Making the handshake timeout the same value may make it a coin flip whether you see a handshake timeout vs. connect timeout exception.

[ManickaP]

I'm still waiting for more data/info on this. As the 10 seconds should be enough even in CI. So the question is why are we seeing the handshake timeouts? We need to understand the problem better.
Also this has the unfortunate effect of making the handshake timeout infinite by default even on the transport level. How do sockets behave in this regard? Do they have some inherent OS level timeout?

Either way, I'm making this draft for now, potentially closing in the future.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.