-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ECONNRESET after response #27916
Comments
I had to run it a few times to get it to fail: ^Cnxt$ nodemon test.js
[nodemon] 1.19.0
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `node test.js`
! 200
^Cnxt$ nodemon test.js
[nodemon] 1.19.0
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `node test.js`
! 200
^Cnxt$ nodemon test.js
[nodemon] 1.19.0
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `node test.js`
! 200
events.js:167
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at TCP.onStreamRead (internal/stream_base_commons.js:111:27)
Emitted 'error' event at:
at Socket.socketErrorListener (_http_client.js:391:9)
at Socket.emit (events.js:182:13)
at emitErrorNT (internal/streams/destroy.js:82:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
at process._tickCallback (internal/process/next_tick.js:63:19)
[nodemon] app crashed - waiting for file changes before starting... |
Adding a |
I think we should always emit a |
It probably happens because the client writes right after the server destroyed the socket (after the response was written). |
Should this be considered a bug? I can see a lot of potential cases where this can cause surprises... especially where developers might think the requests are "ok", "done", "no worries" after a |
I don't know It's a race condition probably hard to fix. |
@lpinca How about one of two possible simple mitigations?
|
|
@lpinca just to be clear, what do you think is the correct behavior here? |
Not sure if correct but it makes sense. |
Do you mean the current behavior? |
Yes, it's weird but I can see why it happens. |
cc: @nodejs/http |
@lpinca It’s not obvious to me why there’s an |
Good point, should not be destroyed my bad, seems like a bug then. |
@ronag what version of Node.js? OS? |
Node 10.13.0 & OSX |
Thanks, I will test tomorrow on macOS, right now I'm using Node.js v10.15.3 on Fedora 30 and I can't reproduce. |
I was able to reproduce on 10.15.3 Now using node v10.15.3 (npm v6.4.1)
nxt$ open test.js ^C
nxt$ node test.js
! 200
^C
nxt$ node test.js
! 200
^C
nxt$
nxt$ node test.js
! 200
^C
nxt$ node test.js
! 200
^C
nxt$ node test.js
! 200
^C
nxt$ node test.js
! 200
^C
nxt$ node test.js
! 200
^C
nxt$ node test.js
! 200
events.js:174
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at TCP.onStreamRead (internal/stream_base_commons.js:111:27)
Emitted 'error' event at:
at Socket.socketErrorListener (_http_client.js:392:9)
at Socket.emit (events.js:189:13)
at emitErrorNT (internal/streams/destroy.js:82:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
at process._tickCallback (internal/process/next_tick.js:63:19) |
I tried fedora 30 in docker and was unable to reproduce |
Expand
I've only added |
Using the following example I am able to reproduce the scenario every time on OSX: const http = require('http')
const server = http.createServer(function (req, res) {
res.end()
})
server.listen(0, function () {
const req = http.request({
port: this.address().port,
method: 'POST',
path: '/'
})
req.on('response', res => {
req.write(Buffer.alloc(32))
})
req.write(Buffer.alloc(32))
}) |
Found even smaller repro (updated previous comment) |
Seems related to OSX. Can't reproduce on debian (docker node:latest) either. |
It's crashed on my Windows with C:\Users\himself65\Desktop\Github\test>node index2.js
events.js:174
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at TCP.onStreamRead (internal/stream_base_commons.js:111:27)
Emitted 'error' event at:
at Socket.socketErrorListener (_http_client.js:392:9)
at Socket.emit (events.js:189:13)
at emitErrorNT (internal/streams/destroy.js:82:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
at process._tickCallback (internal/process/next_tick.js:63:19) |
Can reproduce on both Windows and macOS but it seems my original guess is correct. The socket is destroyed when Line 615 in ac95c2f
because the connection is not kept alive. Perhaps we should make |
Sounds like a good idea. However, it still leaves things a bit tricky to use: const req = http.request({ ... })
src
.pipe(req)
.on('error', onError)
.on('response', res => {
src.unpipe(req) // IMPORTANT or you might get unexpected errors
}) Could maybe |
For me it also occurs on linux (docker |
Somebody has news about this bug? |
@ronag is this problem still there? |
We have in a GCP cloud run project nodejs/mongodb with alpine |
I still get this with nodejs. |
We're getting this exact ECONNRESET error on our actual nodejs production deployment. However, when trying to run the test script, I'm unable to reproduce on my archlinux dev box. Even if I upload the script to our Ubuntu 20.04 production server, I still can't reproduce there with the test script. |
To elaborate on the previous comment, It doesn't actually look like we're running into the error in the context of a network socket. We're running into the error through two node processes doing IPC over file descriptors. If the child process fails in some way, sometimes the parent process will fail with the ECONNRESET. No useful stack traces are generated. |
I am also seeing this error. node:events:498
throw er; // Unhandled 'error' event
^
Error: read ECONNRESET
at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)
Emitted 'error' event on ClientRequest instance at:
at TLSSocket.socketErrorListener (node:_http_client:442:9)
at TLSSocket.emit (node:events:520:28)
at emitErrorNT (node:internal/streams/destroy:157:8)
at emitErrorCloseNT (node:internal/streams/destroy:122:3)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -54,
code: 'ECONNRESET',
syscall: 'read'
} |
+1 here -- exactly the same error when running |
@im6 I was able to fix this on my end by removing the import-statement for the Google Font. Both in my repo as well as in the one you linked to this issue. Seems to be a problem with one of the style loaders rather than webpack or Node. |
Yes you are right @Anatanokami . |
I am also seeing this error. |
Upgrading Node to 16.15 from 16.14 solved the issue for us. Specifically it was happening on webpack start. |
@ronag wdyt? |
I encounter a ton of |
I can't reproduce this with v19.x on macOS. This issue is almost 4 years old and the http module has gone through a lot of changes in those years. The original bug almost certainly has been fixed. Me-too commenters: if you still hit this bug in the latest v18.x or v19.x, please file a new issue and include steps to reproduce. If you're seeing it with v16.x or v14.x, you may be out of luck. Those release lines are in maintenance mode and near their end of life. |
@bnoordhuis I made the same assumption with the new HTTP implementation but this seems to one level lower (possibly socket related race condition having to do with event handlers). It's difficult to reproduce in isolation but easy to reproduce in established projects that I can't share the source code to. We should definitely get a new issue opened up even without reproducible steps so that folks don't go crazy trying to debug and can share/collaborate. |
Is there a solution for this ? Because it happens on my windows |
This was for me a bit of surprising behavior. You can get a connection
error
after a response.Which sometimes prints:
I can't quite decide if this is wrong or right. I feel like it should either be a response or an error, not both... at least it should be consistent and happen just sometimes... Anyone, got any input?
The text was updated successfully, but these errors were encountered: