TLSSocket not destroyed on TCP socket timeout #50884
Comments
Logs from a reproduction:Node logsNotice how the curl requests start coming through again but no Logs from node & curlNetstat logsNotice here how the Send-Q does not increment after it reaches netstat logs |
Logs from a reproduction where send queue of the socket was not fullNode logsNotice that the socket gets correctly destroyed at the timestamp of Logs from node & curlNetstat logsSend-Q keeps incrementing until the timeout is reached at netstat logs |
Additional logs with
|
|
I attempted to find the reason for why the -110 status is not passed correctly and found this piece of code: Lines 1675 to 1678 in f11b206 Not sure if it's related, but seems like it could be. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version
v21.2.0
Platform
Linux aba9cc30a963 5.15.49-linuxkit #1 SMP PREEMPT Tue Sep 13 07:51:32 UTC 2022 aarch64 GNU/Linux
Subsystem
net, tls, http2
What steps will reproduce the bug?
Reproduction repo with instructions can be found here:
https://github.com/mantysalo/http2-issue
I have not found a way to reproduce this locally using just node, as it seems to require a network disconnect, which is difficult to simulate. Also, docker provides a "standard" environment so this should be easily reproduced on any machine.
How often does it reproduce? Is there a required condition?
Reproduces 100% of the time.
Required conditions:
If the Send queue of the TCP socket is not full, a -110 error code is received here
https://github.com/nodejs/node/blob/4e713a3930b0758231ebaf6debbf30bb18eec920/lib/internal/stream_base_commons.js#L214C3-L219C4
and the socket is destroyed properly. (see logs from: #50884 (comment))
What is the expected behavior? Why is that the expected behavior?
The destroy method should be called on the socket once the socket has been terminated by the operating system.
What do you see instead?
The destroy method is not called, and no errors are being thrown or logged when using the socket that the operating system has destroyed.
Additional information
I found a similar issue from 2015: #4417 could be related?
The text was updated successfully, but these errors were encountered: