Error: first argument must be a valid error code number

[creage]

Sometimes our test runs fail with strange error, when running proxy in a "standalone" mode (outside of cypress):

ERROR: The process "2760" not found.

node_modules\ws\lib\Sender.js:121

       throw new Error('first argument must be a valid error code number'); 
       ^ 

 Error: first argument must be a valid error code number

     at Sender.close (node_modules\ws\lib\Sender.js:121:13)
     at WebSocket.close (node_modules\ws\lib\WebSocket.js:281:18)
     at node_modules\http-mitm-proxy\lib\proxy.js:985:38
     at wrapper (node_modules\async\dist\async.js:268:20)
     at eachOfArrayLike (node_modules\async\dist\async.js:484:13)
     at eachOf (node_modules\async\dist\async.js:551:16)
     at awaitable (node_modules\async\dist\async.js:208:32)
     at Object.eachLimit (node_modules\async\dist\async.js:2216:16)
     at Object.awaitable (node_modules\async\dist\async.js:208:32)
     at Proxy.Object.<anonymous>.Proxy._onWebSocketClose (node_modules\http-mitm-proxy\lib\proxy.js:975:11)

We were not able to reproduce this issue manually, but it still occurs in 1 out of 10-15 automated runs.

[bjowes]

Hi @creage - yes, I have also seen this rarely. I have looked through the code but could not find how this can occur. If you manage to find a reproducible case where you see this issue every time (or nearly), please report it.

The freaky part is that this error is related to websockets, which aren't handled by my plugin since authentication with websocket isn't supported. They are handled by a dependency, http-mitm-proxy, which hasn't changed in quite a while. There must be some change in cypress behavior of the websockets it uses between browser and test runner.

[egertaia]

@bjowes Hi. The only case I can reproduce most of the times is when I am testing user credentials on a intranet application that heavily relies on different users doing steps in the app.

My error only occurs when I call cy.ntlmReset(). Not sure but it might be that cypress window is not focused even though it is running in an open mode. In addition I have chrome Web security turned to false.

That's when I saw the error most of the times. I hope it helps you a step forward.

EDIT: After testing it out, I do get this error everytime I call cy.ntlmReset().

cypress:plugin:ntlm-auth Request to config API +862ms
  cypress:plugin:ntlm-auth Created untracked agent for target http://127.0.0.1:62086/ +5ms
  cypress:plugin:ntlm-auth Received reset +19ms
  cypress:plugin:ntlm-auth Removed all agents due to reset +8ms
  cypress:plugin:ntlm-auth Removed and closed all tunnels due to reset +5ms
C:\dev\KV\node_modules\http-mitm-proxy\node_modules\ws\lib\Sender.js:121
      throw new Error('first argument must be a valid error code number');
      ^

Error: first argument must be a valid error code number
    at Sender.close (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\ws\lib\Sender.js:121:13)
    at WebSocket.close (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\ws\lib\WebSocket.js:281:18)
    at C:\dev\KV\node_modules\http-mitm-proxy\lib\proxy.js:983:38
    at wrapper (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\async\dist\async.js:268:20)
    at eachOfArrayLike (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\async\dist\async.js:484:13)
    at eachOf (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\async\dist\async.js:551:16)
    at awaitable (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\async\dist\async.js:208:32)
    at Object.eachLimit (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\async\dist\async.js:2216:16)
    at Object.awaitable (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\async\dist\async.js:208:32)
    at Proxy._onWebSocketClose (C:\dev\KV\node_modules\http-mitm-proxy\lib\proxy.js:975:11)
    at WebSocket.emit (events.js:228:7)
    at WebSocket.emitClose (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\ws\lib\WebSocket.js:211:10)
    at C:\dev\KV\node_modules\http-mitm-proxy\node_modules\ws\lib\WebSocket.js:199:39
    at Receiver.cleanup (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\ws\lib\Receiver.js:520:15)
    at WebSocket.finalize (C:\dev\KV\node_modules\http-mitm-proxy\node_modules\ws\lib\WebSocket.js:199:20)
    at Socket.emit (events.js:223:5)

[creage]

@bjowes I'm trying to debug this issue now, and what I see is the connection closing code being 1006, and here we have some descriptions https://stackoverflow.com/a/19305172/1344835 . That thread has a lot of info actually.

And what I've also noticed, is that this only happens when I create a new proxy instance.

Running entire test as a single user ends green. But switching them almost always fails.

And one more important thing - this only happens when I run HTTPS, I never faced with such issues on HTTP.

EDIT: It looks like it is a WebSocket connections running through HTTPS are causing this issue. We have a custom module/plugin on our page, which uses websockets to communicate to server. Disabling this module makes all tests pass just fine.

P.S. We also have a certificate chain problem, so we have to run using NODE_TLS_REJECT_UNAUTHORIZED flag, which leads to UNABLE_TO_VERIFY_LEAF_SIGNATURE errors during connections.

[creage]

@bjowes I spent some more time on debugging this issue, and since the error is triggered by ws package, which is a direct dependency of http-mitm-proxy, which you updated recently - I've decided to try to downgrade to version 3.1.0 to see if the issue was caused by any regression.

And now I don't see such errors anymore - all of our tests pass, both on HTTP and HTTPS environments. I think I'll stick to version 3.1.0 for now.

[egertaia]

@creage First, huge thanks, this indeed fixed my issue as well, and it explains why it was working at one point.

Downgraded to 3.1.0 does give error when using cypress ^6.0.0, but thats not a problem right now - it's just a warning after all. Hope @bjowes can figure out how to fix this.

[bjowes]

Thanks a lot @creage for working this out and sharing the workaround! From the brief time I've spent on this so far, it seems that some consider Chromes websocket behavior does not follow the standards. The error code 1006 is checked for specifically by the ws package (latest version), which then throws the error.

I think the best solution would be if the ws package had a compatibility mode for this Chrome behavior. I'll raise an issue with ws and discuss it there.

Another option would be to try to filter out this specific error in my plugin, but that would involve registering ws listeners. Currently, ws traffic is ignored (just passed through) by the ntlm-proxy and I would prefer to keep it that way.