Repository navigation
ECONNRESET after response #27916
Description
Activity
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...
I think we should always emit a
ECONNRESETerror if we get aresponseto a request which hasn't.end():ed?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
responseand might e.g. remove theerrorevent listener.I don't know It's a race condition probably hard to fix.
I think both are not viable because there is no guarantee that the full response will be written in a single chunk.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
46 remaining items
I am also seeing this error.
strangely that it only happens on one of my js project, i see this constantly when i use webpack-dev-server
i am using mac M1 version 12.1
node version 16.14node: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' }I am also seeing this error. strangely that it only happens on one of my js project, i see this constantly when i use webpack-dev-server i am using mac M1 version 12.1 node version 16.14
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
webpackorwebpack-dev-server. Both with 16.14.0 and 17.7.0.@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.
@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 .
It is@import()function in .less file that broke the app and emit the error.
Thanks for pointing out.- added 3 commits that reference this issue
on Mar 15, 2022 I am also seeing this error.
Error: read ECONNRESET\n at TLSWrap.onStreamRead (internal/stream_base_commons.js:209:20Reacted by Alex Weininger, Alex Fernandez, outbackStack, vikasainapur, Ryan Atkinson, Zhimeng Wang and Tomáš WitekUpgrading Node to 16.15 from 16.14 solved the issue for us.
Specifically it was happening on webpack start.
Reacted by Arthur ChafonovI encounter a ton of
ECONNRESETon my M1 Mac that other developers can't replicate on x86. I think it may be highly timing depending and my machine is able to reproduce it easily.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.
Reacted by Robert Nagy, Aliaksandr Yeusiuchenia and Damoness@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.
Reacted by Earlam and Aliaksandr YeusiucheniaIs 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
errorafter 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?