SocketError: other side closed #583
Comments
|
@ShrimpAIO do you have an example with another HTTP client of this working? |
|
|
`node:internal/process/promises:245 SocketError: other side closed |
|
So from what I can gather these other HTTP clients may be automatically adding things to the request for you. I'd recommend logging the complete request from something like |
I've made some progress but still not working with these particular proxies. 400 Bad Request400 SocketError: other side closed The IP's are 100% authenticated as the superagent code works both on Ubuntu and Windows.. For context, the code being tried now is as below; |
|
Seems like another proxy provider refuses to work; |
|
Maybe this is something not yet achievable in Undici see #569 |
|
And #568 might help you too |
|
Ok; |
|
This also happened to me when making a normal request to for example "http://nvidia.com" using the example from the Quickstart. I do get some response but after that my app crashes: response received 302
headers {
location: 'http://www.nvidia.com/',
'content-type': 'text/html',
'cache-control': 'private',
connection: 'close'
}The application crashes on: events.js:292
throw er; // Unhandled 'error' event
^
SocketError: other side closed
at Socket.onSocketEnd (/Users/<my-username>/<my-project>/node_modules/undici/lib/client.js:916:22)
at Socket.emit (events.js:327:22)
at endReadableNT (internal/streams/readable.js:1327:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
Emitted 'error' event on RequestResponse instance at:
at emitErrorNT (internal/streams/destroy.js:106:8)
at emitErrorCloseNT (internal/streams/destroy.js:74:3)
at processTicksAndRejections (internal/process/task_queues.js:80:21) {
code: 'UND_ERR_SOCKET' |
|
Do you have the same problem with 4.0.0-alpha.2? |
|
Just tried and this still happend with 4.0.0-alpha.2 |
|
Can you please provide a repro example? |
|
I had a pretty similar error: I build a small reproduction, its just requesting a lot of files one by one from cloudfront. Note: this does happen consistently but it might take a few requests. Edit: Edit2: |
|
|
|
@MoritzLoewenstein Could you use a Node.js server to reproduce? |
|
Hey, I added a node server. The issue is indeed an invalid Content-Length header, if I don't set the Content-Length header on the server I cant reproduce the issue. |
Do you know what's the value of this? |
|
When I dont set the Content-Length header, node will set the Transfer-Encoding header to chunked (= no Content-Length header). |
|
Can you prepare an example to reproduce the problem? You can also use a |
|
My provided example should be sufficient to show the problem: https://github.com/MoritzLoewenstein/undici-fetch-repro I investigated a bit more: When the code enters here is the parser printed in this function: |
|
It's not enough for a unit test. |
|
Alright, I will see if I can narrow it down. |
Thanks! Tracking down those conditions is hard :(. |
|
The reason undici crashes is an incorrect One more thing I found out in the process, undici will keep the node process open if Current reproduction with server & files is here: https://github.com/MoritzLoewenstein/undici-fetch-repro |
|
Ok, I have written a test that will fail, but I think I cant push it because of that. here is the code for the test:test('dont crash on unexpected Transfer-Encoding Header', async (t) => {
t.plan(2)
const server = createServer((req, res) => {
res.setHeader('Content-Type', 'text/plain')
res.removeHeader('Connection')
res.removeHeader('Keep-Alive')
res.removeHeader('Transfer-Encoding')
const str = 'Chunked Transfer Encoding Test'
res.write(str.repeat(832))
res.end(str)
})
t.teardown(server.close.bind(server))
server.listen(0, async () => {
const client = new Client(`http://localhost:${server.address().port}`)
t.teardown(client.close.bind(client))
process.on('uncaughtException', () => {
t.fail('uncaughtException happened')
})
try {
await client.request({
path: '/',
method: 'GET'
})
t.pass('request successful')
} catch (err) {
t.pass('error happened')
} finally {
process.removeListener('uncaughtException')
}
})
}) |
|
Your test does not run successfully, it has some issues with promises, callbacks and how tap needs things laid out. However, I have adapted your test to run and it passes on master (see #822). My understanding is that this is fixed. |
|
Shouldn't this be changed? Lines 989 to 993 in a3e0fdc To: - if (parser.statusCode && !parser.shouldKeepAlive) {
+ if (parser.statusCode || !parser.shouldKeepAlive) {
// We treat all incoming data so far as a valid response.
parser.onMessageComplete()
return
} |
|
Additional findings:
|
|
The fix is to call This definitely seems like a major anti-pattern @mcollina @ronag. We don't explicitly state anywhere in the
|
|
I dont think this issue should be closed. @mcollina |
|
This issue has been closed since 3 years ago; please open a new one with a description and an |
… within the timeout of the last one - nodejs/undici#583
|
I'm still facing the issue in 2024. For anyone pulling their hair over this, this issue is not at all encountered with the bun runtime, give it a shot. |
|
Any update on this? I'm consuming the body with |
|
I have managed to fix this and other socket errors in my applications by limiting the nuber of connections NodeJS is allowed to open to the server. I observed that the node process was opening too many connections to the server, that is, using too many local ports of the host (16000+ in my case) and eventually these connections would end abruptly and cause the error. The number of connections can be limited via setting the 50 might not be an ideal number for you and you might still face the issue or your application might slow down because the process has lesser number of connections. You need to trial and error and find a number that works for you. 100 worked well for me when I did over 2 million async API calls for testing the limits. You can monitor the number of ports used by your node process on unix based systems via the following command Bun used around 400-500 ports and was faster than NodeJS. I've tested using I haven't dug into whether the OS limits the number of connections, runs out of them or NodeJS is unable to handle them If this doesn't fix the issue for you and you want to dig in further, a packet capture can be helpful. I did a pcap and analyzed the packets in Wireshark. You'd want to look for the flow, source, destination, origin of the Also, if the server you're connecting to has rate limits, give a look at what it does to new connection requests and exising connections once the limits are hit Overall, this issue is now fixed for me and for all of the people I've recommended the above mentioned fix. |
|
The bug can popup when the disk is full also |
|
@aleluff This may be one of the cause as well. I had plenty of disk space available during working on this. |
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
We realized that the sdk is run on client's server and we can't control the nodejs version or if the have `fetch` polyfill. Also one user saw our sdk failing with TLSSocket.onSocketEnd TypeError terminated other.side closed. The stack trace we saw was pointing to undinci nodejs/undici#583 Which looks is the nodejs fetch implementatin. So we try to use node-fetch to see if this mitigates the error
_128fx128f.png){kind=link}
|
fwiw, I was able to reproduce this consistently while running the VS Code interactive debugger on test cases of some api code I was writing using the I assume there's other ways to fix this, but adding to the request headers seems to have avoided it for now. |
Upon connecting to a proxy with user:pass it's all good, but when I try to make a request to an proxy which is IP authenticated, I get 'SocketError: other side closed'.
I'm not sending the proxy-authorization header as it's not needed.
Blanked the proxy ip and port below.
The text was updated successfully, but these errors were encountered: