Skip to content

Erorr : read ECONNRESET (MacOS NodeJS v16 and v14) #40468

Description

@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.

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

Activity

  1. lpinca commented on Oct 16, 2021

    @lpinca
    Member

    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?

  2. added
    httpIssues and PRs related to the http subsystem.
    on Oct 16, 2021
  3. dmvict commented on Oct 17, 2021

    @dmvict
    Author

    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?

  4. added
    httpsIssues and PRs related to the https subsystem.
    tlsIssues and PRs related to the tls subsystem.
    and removed
    httpIssues and PRs related to the http subsystem.
    on Oct 17, 2021
  5. lpinca commented on Oct 17, 2021

    @lpinca
    Member

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

  6. dmvict commented on Oct 18, 2021

    @dmvict
    Author

    @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.

  7. lpinca commented on Oct 18, 2021

    @lpinca
    Member

    @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)
    
  8. dmvict commented on Oct 19, 2021

    @dmvict
    Author

    @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.

  9. dmvict commented on Oct 21, 2021

    @dmvict
    Author

    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.

  10. dmvict commented on Oct 26, 2021

    @dmvict
    Author

    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.

  11. alexhafner commented on Nov 22, 2021

    @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.

  12. Zuckjet commented on Dec 23, 2021

    @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 ?

  13. vitalipf commented on Jan 11, 2022

    @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.

  14. bnoordhuis commented on Sep 27, 2023

    @bnoordhuis
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    httpsIssues and PRs related to the https subsystem.tlsIssues and PRs related to the tls subsystem.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions