Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more informative error messages when cypress verify hangs #3807

Closed
wants to merge 7 commits into from

Conversation

stuartsan
Copy link

@stuartsan stuartsan commented Mar 22, 2019

address #819

The purpose of this change is to add better visibility when cypress run hangs indefinitely on the verification step.

When running the smoke test, the child process's stderr contains useful information but it is currently being swallowed when the process doesn't exit. The proposed change writes the child's stderr to the parent's.

The result is that instead of seeing this:

Verifying Cypress can run

With no further output, I now see this:

Verifying Cypress can run
...
A JavaScript error occurred in the main process
Uncaught Exception:
Error: Failed to get 'appData' path
    at Object.<anonymous> (/tmp/lib/resources/electron.asar/browser/init.js:149:39)
    at Object.<anonymous> (/tmp/lib/resources/electron.asar/browser/init.js:173:3)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:503:32)
    at tryModuleLoad (module.js:466:12)
    at Function.Module._load (module.js:458:3)
    at Function.Module.runMain (module.js:605:10)
    at startup (bootstrap_node.js:167:16)
    at bootstrap_node.js:589:3

And then, after googling and fixing my specific underlying problem (Electron's default appData path, ~/.config, was read-only), if I do cypress run again it works fine.

This doesn't address the underlying issue of why cypress --smoke-test seems to be not exiting when this kind of failure happens, but it at least adds visibility so folks can self-serve and fix their specific problem more easily.

See also: #819 (comment).

Validation

To validate this, I've made the change manually to the cypress CLI source within my own project. I cloned the cypress repo and fiddled around but couldn't figure out a good way to test it within here.

This doesn't seem like it lends itself well to an automated test (cause it would be hanging on purpose)...what I wanted to do manually to reproduce the problem case is something like:

mkdir readonly
chmod 444 readonly

And then (on linux) set XDG_CONFIG_HOME (per this) to tell Electron to use that as the appData path, and do cypress run (or maybe cypress verify for a smaller case).

Anyway, I read the contributing docs but couldn't figure out how to do that within this repo. I'm hoping that between feedback from the CI tests, and maintainers, I can get an idea if this change is legit and if there's anything else I should do to validate.

@CLAassistant
Copy link

CLAassistant commented Mar 22, 2019

CLA assistant check
All committers have signed the CLA.

@@ -65,7 +65,7 @@ const runSmokeTest = (binaryDir) => {

debug('smoke test command:', smokeTestCommand)

return Promise.resolve(util.exec(cypressExecPath, args))
return Promise.resolve(util.exec(cypressExecPath, args, { stdio: ['pipe', 'pipe', process.stderr] }))
Copy link
Author

@stuartsan stuartsan Mar 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One specific concern I have but am unsure how to test is, the onSmokeTestError callback contains:

return throwFormErrorText(errors.missingDependency)(err.stderr || err.message)

And possibly the suggested change is hosing its ability to hook into err.stderr, for those cases where the smoke test exits with useful info on stderr.

Copy link
Author

@stuartsan stuartsan Mar 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just pushed an update that addresses this by preserving stderr in the child as well

function smokeTestExec () {
let child = util.exec(cypressExecPath, args)

if (child.stderr) {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at https://github.com/sindresorhus/execa/tree/v0.10.0, no idea why sometimes stderr isn't there, but the unit tests fail without this guard 🤷‍♂️ .

@stuartsan
Copy link
Author

stuartsan commented Mar 22, 2019

Status: this is ready for review.

There is a failing integration test, but it doesn't seem related to the code change (AFAICT)

Copy link

@linuxdropout linuxdropout left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

child can safely be declared with const here as a best practice.

I also kinda like returning a new Promise and calling it's resolve to capture the functionality inside smokeTestExec, if you're creating a function anyway it feels more explicit. But it's neither here nor there.

Great work though. Not having this err output has been a pain point for our team for a while now 👌

@jennifer-shehane jennifer-shehane requested a review from a team March 25, 2019 11:35
@brian-mann brian-mann self-requested a review March 25, 2019 16:47
@jennifer-shehane
Copy link
Member

Hey @stuartsan, we haven't forgotten about you. We will make sure to review this before our next release. 😄

@stuartsan
Copy link
Author

Thanks @jennifer-shehane, all good, literally zero rush on my end, :)

@sebastianheise
Copy link

While not actually testing this PR, it did give the crucial tip to check for permissions on ~/.config/. So this solved my cypress verify issue. More debug output is always good. 👍

@kuceb
Copy link
Contributor

kuceb commented May 1, 2019

I think adding a timeout to the smoke test process is a better solution here, we can then print you a proper error message and not hang the process forever.

If the process does not exit within 10s, we'll kill it and print its stderr telling you the smoke test timed out

PR for adding the timeout here #4080

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants