cypress: Error: This socket has been ended by the other party

Current behavior:

When I run my specs headless on the CLI, Cypress closed unexpectedly with a socket error.

Error code:

Error: This socket has been ended by the other party
    at TLSSocket.writeAfterFIN [as write] (net.js:407:14)
    at ClientRequest.<anonymous> (/Users/estefania.fernandez/Library/Caches/Cypress/4.0.1/Cypress.app/Contents/Resources/app/packages/server/node_modules/http-proxy/lib/http-proxy/passes/ws-incoming.js:115:16)
    at ClientRequest.emit (events.js:203:13)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:575:27)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:116:17)
    at TLSSocket.socketOnData (_http_client.js:449:22)
    at TLSSocket.emit (events.js:203:13)
    at addChunk (_stream_readable.js:295:12)
    at readableAddChunk (_stream_readable.js:276:11)
    at TLSSocket.Readable.push (_stream_readable.js:210:10)
    at TLSWrap.onStreamRead (internal/stream_base_commons.js:166:17)
 {
  code: 'EPIPE'
}
Error: This socket has been ended by the other party
    at TLSSocket.writeAfterFIN [as write] (net.js:407:14)
    at ClientRequest.<anonymous> (/Users/{my.user}/Library/Caches/Cypress/4.0.1/Cypress.app/Contents/Resources/app/packages/server/node_modules/http-proxy/lib/http-proxy/passes/ws-incoming.js:115:16)
    at ClientRequest.emit (events.js:203:13)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:575:27)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:116:17)
    at TLSSocket.socketOnData (_http_client.js:449:22)
    at TLSSocket.emit (events.js:203:13)
    at addChunk (_stream_readable.js:295:12)
    at readableAddChunk (_stream_readable.js:276:11)
    at TLSSocket.Readable.push (_stream_readable.js:210:10)
    at TLSWrap.onStreamRead (internal/stream_base_commons.js:166:17)

The Test Runner unexpectedly exited via a exit event with signal SIGSEGV

Please search Cypress documentation for possible solutions:

https://on.cypress.io

Check if there is a GitHub issue describing this crash:

https://github.com/cypress-io/cypress/issues

Consider opening a new issue.

----------

Platform: darwin (19.3.0)
Cypress Version: 4.0.1
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @ycbm/cypress-e2e@0.0.0 stag: `cypress run --env configFile=stag`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @ycbm/cypress-e2e@0.0.0 stag script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users{myuser}//.npm/_logs/2020-02-14T08_51_09_625Z-debug.log

NPM Complete log:

0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/bin/node', '/usr/local/bin/npm', 'run', 'stag' ]
2 info using npm@6.9.0
3 info using node@v10.16.3
4 verbose run-script [ 'prestag', 'stag', 'poststag' ]
5 info lifecycle @ycbm/cypress-e2e@0.0.0~prestag: @ycbm/cypress-e2e@0.0.0
6 info lifecycle @ycbm/cypress-e2e@0.0.0~stag: @ycbm/cypress-e2e@0.0.0
7 verbose lifecycle @ycbm/cypress-e2e@0.0.0~stag: unsafe-perm in lifecycle true
8 verbose lifecycle @ycbm/cypress-e2e@0.0.0~stag: PATH: /usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/Volumes/Seguridad/YCBM-GIT/ycbm-cypress/js/packages/cypress-e2e/node_modules/.bin:/usr/local/opt/gettext/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands
9 verbose lifecycle @ycbm/cypress-e2e@0.0.0~stag: CWD: /Volumes/Seguridad/YCBM-GIT/ycbm-cypress/js/packages/cypress-e2e
10 silly lifecycle @ycbm/cypress-e2e@0.0.0~stag: Args: [ '-c', 'cypress run --env configFile=stag' ]
11 silly lifecycle @ycbm/cypress-e2e@0.0.0~stag: Returned: code: 1  signal: null
12 info lifecycle @ycbm/cypress-e2e@0.0.0~stag: Failed to exec stag script
13 verbose stack Error: @ycbm/cypress-e2e@0.0.0 stag: `cypress run --env configFile=stag`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:301:16)
13 verbose stack     at EventEmitter.emit (events.js:198:13)
13 verbose stack     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:198:13)
13 verbose stack     at maybeClose (internal/child_process.js:982:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)
14 verbose pkgid @ycbm/cypress-e2e@0.0.0
15 verbose cwd /Volumes/Seguridad/YCBM-GIT/ycbm-cypress/js/packages/cypress-e2e
16 verbose Darwin 19.3.0
17 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "run" "stag"
18 verbose node v10.16.3
19 verbose npm  v6.9.0
20 error code ELIFECYCLE
21 error errno 1
22 error @ycbm/cypress-e2e@0.0.0 stag: `cypress run --env configFile=stag`
22 error Exit status 1
23 error Failed at the @ycbm/cypress-e2e@0.0.0 stag script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

Desired behavior:

Cypress is not closed and I can run all my tests without any problem.

Test code to reproduce

I have 4 specs, all of them have the following structure:

/* global cy, before, Cypress */
const env = Cypress.env();

describe('PageName', function () {
	describe('PageName Checks', () => {
		before(() => {
			go to the page. 
		});

		it....
	});
	
	describe('PageName Actions', () => {
		beforeEach(() => {
                        go to the page and accept the cookies. 
		});

		it....
	});
});

My config file looks like:

{
    "env": {
        "appURL": "URL",
    }
}

Versions

Platform: darwin (19.3.0) Cypress Version: 4.0.1 Electron 78 (headless) Mac OS version: Catalina 10.15.3 (19D76).

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 5
  • Comments: 60 (13 by maintainers)

Most upvoted comments

I believe the root cause of this error is that, for a short amount of time, there is no error handler on the underlying socket for websocket connections that are proxied through Cypress. An error handler is only attached after the proxy request is successfully upgraded: https://github.com/http-party/node-http-proxy/blob/9bbe486c5efcc356fb4d189ef38eee275bbde345/lib/http-proxy/passes/ws-incoming.js#L120-L133

So, if the other end of the websocket disappears unexpectedly this uncaught error event on the browser socket can cause a crash.

However, I haven’t been able to reproduce this locally. Can someone share an example repository that shows this error?

I’ve also been experiencing this today, both on Cypress v4.2.0 and 4.1.0. I can no longer get through an entire test run (65 tests, ~30m locally on a MacBook) without Cypress crashing. Below is the output from Cypress when it’s crashed, both on 4.1.0 and 4.2.0.

4.1.0:

Any updates on this guys? Anybody from Cypress.io to have some official statement?

This is a blocker for some portion of our Cypress tests and we do not have stable results because of this.

PLEASE PRIORITIZE THIS!!!

Well, in my case, the crash is going because of constantly broken WebSockets requests during a particular test, like 10-20 in the row. Anyway, I guess Cypress should handle that in some ways, at least by try > catch?

@uweku Hmm, I cannot find any incoming email from you in our support inbox from the relevant dates, containing this issue number, or from your name. Can you email it to me directly by using the email address on my GitHub profile? Thanks!

@TheWanderingWalnut Actually, I spent a day trying to reproduce this issue by playing with websockets, but was unable to get the same error y’all are experiencing. Real world apps can have a lot of complexity that can cause issues that are very very difficult to isolate by shooting in the dark. Until someone can supply a reproducible example to debug with, or until someone else finds the problem and opens a PR to fix it, there is no way that progress can be made on this issue. I hope this situation is understandable.

Done 😃

@BiosBoy Yeah, unfortunately it seems Cypress is uninterested in fixing their application unless their users do all the legwork… -__-

Seems like we’re left alone here? 😦

exactly. @BiosBoy I think it should handle this in someway.

No, I didn’t see any request like that on my terminal.