catch child process killed with a signal #5810
Conversation
|
Thanks for the contribution! Below are some guidelines Cypress uses when doing PR reviews.
PR Review ChecklistIf any of the following requirements can't be met, leave a comment in the review selecting 'Request changes', otherwise 'Approve'. User Experience
Functionality
Maintainability
Quality
Internal
|
|
Test summary
Run details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
bahmutov
changed the title
| context('detects kill signal', function () { | ||
| it('exits with error on SIGKILL', function () { | ||
| this.spawnedProcess.on.withArgs('exit').yieldsAsync(null, 'SIGKILL') | ||
|
|
||
| return spawn.start('--foo') | ||
| .then(() => { | ||
| throw new Error('should have hit error handler but did not') | ||
| }, (e) => { | ||
| debug('error message', e.message) | ||
| snapshot(e.message) | ||
| }) | ||
| }) | ||
| }) | ||
|
|
There was a problem hiding this comment.
@bahmutov I think it would be worth it to add an e2e test for this, since it involves multiple processes, what do you think?
There was a problem hiding this comment.
would be tricky though, maybe not worth the time investment unless we have issues with this PR going forward
There was a problem hiding this comment.
I am not so sure e2e would be worth it
- we don't have e2e tests for CLI right now
- Node side (that one that delivers
code: null, signal: <name>is pretty solid :) - we have only changed our handling, which is covered by the tests
- finally, so far this has affected only very small number of our users I believe, otherwise we would hear about it again and again
Co-Authored-By: Zach Bloomquist <github@chary.us>
Co-Authored-By: Zach Bloomquist <github@chary.us>
|
love the new wording, will pull and update snapshot |
| return spawn.start('--foo') | ||
| .then(() => { | ||
| throw new Error('should have hit error handler but did not') | ||
| }, (e) => { |
There was a problem hiding this comment.
the .catch() pattern is highly preferred over passing two arguments to .then
There was a problem hiding this comment.
well, in this case, catch would let false positive slide (we really want NOT to resolve). Ideally we would plug in https://www.chaijs.com/plugins/chai-as-promised/
return spawn.start('--foo').should.eventually.rejectWith(...)
* WIP: catch child process killed with a signal * unit test getError * we don't need custom exit code * Update cli/lib/exec/spawn.js Co-Authored-By: Zach Bloomquist <github@chary.us> * Update cli/lib/errors.js Co-Authored-By: Zach Bloomquist <github@chary.us> * update snapshots with wording
User facing changelog
If the Test Runner child process is killed with a signal like
SIGKILLorSIGBUS, the NPM CLI process shows an error and exits with non-zero code, no longer swallowing the error.Additional details
Child Electron process could crash for some reason (like running out of memory) while running tests, and close. In that case the CLI parent process would receive
code: null, signal: <name>which is different from successful exitcode: 0, signal: nullor a failded test exitcode: 1, signal: null. But the CLI parent process would just do truthy checkif (code) { reject ... }thus swallowing the crash.How has the user experience changed?
The users should get better CI information, that no longer shows passing green build while the tests crashed in Electron browser.
PR Tasks
Local testing
npm start. This will start the GUI in global modepslike thisnode /Users/gleb/git/cypress/scripts/start.jsprocess likekill -9 68522and the exit code should be non-zero