Repository navigation
TLS handshake has no timeout, one stalled handshake can stop a pool from creating any new connections indefinitely. #4834
Description
Describe the bug
The TLS handshake has no timeout, and the underlying network stream has no timeout. This means, should a TCP connection go down without a FIN/RST being sent (which can happen) during the TLS handshake, then
- That connection will never open and hang indefinitely.
- Since only one "worker/thread" can open a connection for the pool at a time, the pool can never grow as it is blocked waiting for that stuck connection to complete opening the connection.
To reproduce
The issue has been replicated in my own fork. You can run the two tests to see the issue and the expected behavior with a fix applied.
In short, the tests:
- Opens a connection to the DB via a Port forwarder. This probably does not need to be done.
- Instructs the test to "pause" all TCP connections just before the TLS handshake. The pause here simulates a TCP disconnect in which no FIN/RST packets are sent.
- Another connection is opened.
- Just before the TLS handshake, the TCP connection (already opened) is paused.
- Since the stream has no timeout and no cancellation token is passed into tls handshake, the open connection hangs forever.
- One of the test demos shows that once we reach this stage, we can not create a new connection, even if the port forwarder does NOT pause any connections.
Expected behavior
The existing Timeout as set in SqlConnectionStringBuilder.ConnectTimeout should be respected. In the case described above, an exception should be thrown when the timeout is reached. After that, new connections should eventually be possible.
The PR and tests demonstrate enabling a fix, and these tests passing.
Further technical details
Demonstrated on Main, affects version 7.1.1
Additional context
Reacted by Łukasz Krzywizna
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
[-]TLS handshake has no timeout, One stalled handshake can stop a pool from creating any connections indefinitely.[/-][+]TLS handshake has no timeout, one stalled handshake can stop a pool from creating any new connections indefinitely.[/+]github-actions commentedon Oct 13, 2026
🔍 Triage Summary
Analysis
A TCP connection that silently stalls (no FIN/RST) during the TLS handshake never times out, because the handshake and the underlying stream ignore
ConnectTimeout. Because the pool opens connections serially, one stuck open blocks all pool growth. The likely affected components are the SNI TLS handshake path (managed SNI SSL stream) and pool connection creation. Severity looks like P1/P2: indefinite hang and pool starvation, but it requires a network failure mode.Next Steps
mdaigle commentedon Oct 13, 2026
Hey @LukeButters, thanks for the report. Sending the appropriate cancellation token all the way down the stack like you've done in your repro looks like it will be the right approach. I can pick this up as part of #3459, or if you want to tackle this yourself, please do go ahead.
I also want to call your attention to some related app context switches. These will improve other symptoms that your report mentioned: UseConnectionPoolV2 and UseOverallConnectTimeoutForPoolWait. Pool V2 will let you create connections within the same pool in parallel. UseOverallConnectTimeoutForPoolWait will count time spent waiting in the pool against the connect timeout.