Erorr : read ECONNRESET (MacOS NodeJS v16 and v14)

[dmvict]

Version

v16.11.1

Platform

Mac OS X

Subsystem

No response

What steps will reproduce the bug?

I have only github workflow MacOS machines.

• make fork of https://github.com/Wandalen/wHttp.git
• run test workflow

How often does it reproduce? Is there a required condition?

In new minor version of Node.js v16.x and v14.x - every run.

Experimental branch, run on Node.js v16.11.1

In older verseion - v16.11.1 and v14.17.4 - no errors

Experimental branch, run on Node.js v16.6.2

What is the expected behavior?

Expected no errors. Same workflows on Ubuntu and Windows have no errors.
https://github.com/Wandalen/wHttp/runs/3892798684?check_suite_focus=true

What do you see instead?

 = Message of Error#9
    read ECONNRESET

 = Beautified calls stack
        
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:220:20)
        read ECONNRESET
    
        Test check ( TestSuite::Tools.mid.Http / TestRoutine::retrieve / array of URIs # 2 ) ... failed, throwing error
    at Object.<anonymous> (/Users/runner/work/wHttp/wHttp/node_modules/wTesting/proto/wtools/atop/testing/entry/Exec:6:3)
      Failed ( throwing error ) TestSuite::Tools.mid.Http / TestRoutine::retrieve in 1.669s

 = Throws stack
    thrown at Object.process @ /Users/runner/work/wHttp/wHttp/node_modules/wTools/proto/wtools/abase/l0/l1/zErr.s:1450:11
    ExitCode : -1

    Thrown 1 error(s)
 = Exposed
    Passed test checks 1 / 2
    errno : -54
    Passed test cases 1 / 2
    code : 'ECONNRESET'
    Passed test routines 0 / 1
    syscall : 'read'
    Test suite ( Tools.mid.Http ) ... in 1.736s ... failed

 = Process
    Current path : /Users/runner/work/wHttp/wHttp
    Exec path : /Users/runner/hostedtoolcache/node/16.11.1/x64/bin/node /Users/runner/work/wHttp/wHttp/node_modules/wTesting/proto/wtools/atop/testing/entry/Exec .run proto/** rapidity:-3

Additional information

No response

[lpinca]

This might be caused by the libuv 1.42.0 update. Are you able to write a test case that only uses Node.js core modules?

[dmvict]

This might be caused by the libuv 1.42.0 update. Are you able to write a test case that only uses Node.js core modules?

I've not written such tests. Do you have any instructions/tutorials for writing tests with Node.js core modules?

[lpinca]

@dmvict a simple Node.js script that only uses core modules and reproduces the issue would be ok.

[dmvict]

@lpinca Maybe, I've has a mistake. This simple script works fine (workflow run).

I do not know what conditions are needed to reproduce the error.

[lpinca]

@dmvict you need at least to use the https module as there is this in the error stack trace:

at TLSWrap.onStreamRead (node:internal/stream_base_commons:220:20)

[dmvict]

@dmvict you need at least to use the https module as there is this in the error stack trace:

at TLSWrap.onStreamRead (node:internal/stream_base_commons:220:20)

The new scrip also works fine (workflow run).

Maybe, the problem is in dependency. Thank you for help.

[dmvict]

I made many experiments. In the last I replaced external library on internal module and took same error ( workflow ).

It seems that routine throw error if it is exported from module. I will made this experiment later.

[dmvict]

I've reproduced the problem with only Node.js modules. If routine exports code with module https then on MacOS will throw uncaught error read ECONNRESET ( workflow ).

When I was attended error, then the workflow was passed ( workflow ).

I think it gives more information for the problem.

[Moebits]

Hello, I am getting this error every single time I run node (v16.13.0) on macOS Monterey 12.0.1

node:events:368
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:220:20)
Emitted 'error' event on ClientRequest instance at:
    at TLSSocket.socketErrorListener (node:_http_client:447:9)
    at TLSSocket.emit (node:events:390: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 literally cannot run anything.

EDIT: Downgrading node to v16.6.2 fixes this issue.

[alexhafner]

I ran into this issue using craco on MacOS Big Sur 11.16. The issue was intermittent on smaller projects and permanently present on larger ones.

Thanks for mentioning the workaround to downgrade node to 16.6.2 @Tenpi it works for me as well. The next release up, 16.7.0 which also introduces the dependency upgrade by @lpinca for libuv 1.42.0 [cf5e5b5] #39525 reproduces the issue.

[Zuckjet]

Same error for node v16.13.1:

node:events:368
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:220:20)
Emitted 'error' event on Request instance at:
    at Request.onRequestError (xxxxxxxxxx/node_modules/request/request.js:877:8)
    at ClientRequest.emit (node:events:390:28)
    at TLSSocket.socketErrorListener (node:_http_client:447:9)
    at TLSSocket.emit (node:events:390: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'
}
error Command failed with exit code 1.

And I also tried node v17.3.0, but still have same error. I cannot downgrade node to v16.6.2, since my project dependencies require node >=16.10.0.

Is there any solution to fix this error right now, thanks ?

[vitalipf]

We experience the same issue with Nodejs v16.13.0 and Mac Intel 12.0.1. I can confirm that downgrading to Nodejs v16.6.2 fixes the problem. It also works in Node 12 and 14.
The problem itself is originated by the fact that after http(s) communication is done and the client sends TCP FIN packet, server (or proxy in the middle) responds with TCP RST. It seems that Nodejs became sensitive to this while in the past it didn't bother as well as browsers.
The workaround would be to catch and ignore ECONNRESET error if actual data has been already retrieved.

Unfortunately I can't say if it's reproduced on any other OS or not.

[bnoordhuis]

v16.x went out of support earlier this month and newer versions aren't affected, as far as I'm aware, so I'll go ahead and close this.