-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
🐛 Bug: Negative functional tests started to throw "Uncaught Error" after mocha update to 8.2.0 #4481
Comments
For me, Downgrading mocha to 8.1.3 figures it out |
We experience the same issue with mocha upgrade to 8.2.0 |
We are also experiencing the same issue, we have a simple test like the one below that fails after upgrading. After downgrading the test succeeds reliably.
|
We are also experiencing this issue!!! |
Tried bumping to 8.2.0 in several projects, in some of them we were experiencing this issue so we downgraded to 8.1.3 in some of them. By using 8.1.3 it solved the issue, this is definitely a breaking change. |
For everyone other than the original reporter in this issue: I need more information. Please provide:
@StefanSafeguard I can't reproduce that: // test.js
const should = require('should');
it('should do a thing', async function() {
let error;
try {
await foo();
} catch(err) {
error = err;
}
should.exist(error);
}); Used mocha v8.2.0 and the latest version of |
I am pretty sure that this is because Mocha v8.2.0 needs to trap unhandled rejections. It's very likely that what's happening is this: Previously to v8.2.0, your test (or code-under-test) was raising an unhandled rejection and was being silently ignored. Now it is not. I'm going to test this theory on the appium-espresso-driver repo; hopefully it won't be to onerous to get a dev environment going. |
It's going to be too difficult to debug that appium driver, so... I really need a minimal, complete, verifiable example for this. If it's a webdriver-specific thing, a repo with the proper dependencies, configuration, and a single test should do it. |
@boneskull Thank you for checking this issue. Unfortunately I was not able to reproduce it by just awaiting a generic function that is expected to be rejected. It must be some complex interaction that happens in |
@mykola-mokhnach yeah, I think that's probably the case. but I also think I'm probably right about the unhandled rejection behavior. Mocha really ought to be delegating what to do in this case to Node. I am going to propose a workaround... maybe you can test it for me? |
will have a PR up soon |
Of course, Just tell me what to do. Unfortunately I'm in a different time zone (CET), so my responses might arrive late |
@boneskull I'm PDT, have an affected project, and can help test as well. Thanks for looking into this! |
This is not intended as a _fix_ for #4481, since it's possible that Mocha's behavior in v8.2.0 uncovers false positives. In other cases--depending on the use-case--they are not false positives at all, but rather annoyances that depended on the pre-v15 behavior of Node.js to only issue warnings. This PR changes the behavior of Mocha so that it will re-emit unhandled rejections to `process` _if_ they did not generate from Mocha. If the rejection generated from Mocha, then we treat it as an uncaught exception, because Mocha should not be in the business of ignoring its own unhandled rejections. The logic for detecting an "error originating from Mocha" is not exhaustive. Once an unhandled rejection is re-emitted to `process`, Node decides what to do with it based on how it is configured to handle unhandled rejections (strict, warn, quiet, etc.). Added a public method to `errors` module; `isMochaError()` Ref: #4481
Please checkout #4489 and see if it works better for you. |
perhaps |
I've checked out the |
Btw, I got some interesting traceback while playing with version 8.2.0:
|
ok good |
hmm no that doesn't seem right either. |
I don't think it's wise to merge #4489 or any fixes here until I have a minimal case I can debug with, sorry. Hopefully somebody can provide this. |
@mykola-mokhnach wait, is that "multiple done" coming from v8.2.0 proper, or my branch? |
@boneskull Your branch is fine. That error was coming from the currently released 8.2.0 version |
ok, I'll reconsider not merging the fix. |
This is not intended as a _fix_ for #4481, since it's possible that Mocha's behavior in v8.2.0 uncovers false positives. In other cases--depending on the use-case--they are not false positives at all, but rather annoyances that depended on the pre-v15 behavior of Node.js to only issue warnings. This PR changes the behavior of Mocha so that it will re-emit unhandled rejections to `process` _if_ they did not generate from Mocha. If the rejection generated from Mocha, then we treat it as an uncaught exception, because Mocha should not be in the business of ignoring its own unhandled rejections. The logic for detecting an "error originating from Mocha" is not exhaustive. Once an unhandled rejection is re-emitted to `process`, Node decides what to do with it based on how it is configured to handle unhandled rejections (strict, warn, quiet, etc.). Added a public method to `errors` module; `isMochaError()` Ref: #4481 Signed-off-by: Christopher Hiller <[email protected]>
Marking this as fixed by #4489. By "fixed" I mean, the reported cases are behaving as Mocha thinks they should, and nobody's reported anything since. If you're reading this and think this is still an issue for you then please do file a new issue with a minimum reproduction we can work with. Cheers! |
Prerequisites
faq
labelnode node_modules/.bin/mocha --version
(Local) andmocha --version
(Global). We recommend that you not install Mocha globally.Description
After the recent mocha bump to 8.2.0 our functional tests on CI started to throw unexpected "Uncaught Error" failures while before everything was working kist fine.
Steps to Reproduce
npm i
on itgulp transpile
to transpile the sourcenpx mocha --timeout 6000000 --reporter mocha-multi-reporters --reporter-options config-file=./ci-jobs/mocha-config.json --recursive build/test/functional/ -g @skip-ci -i --exit
Expected behavior: [What you expect to happen]
The test should pass
Actual behavior: [What actually happens]
The test is shown twice as passing and failing with an "Unexpected error" exception:
The results of full CI run: https://dev.azure.com/AppiumCI/Appium%20CI/_build/results?buildId=11913&view=logs&j=ea3a8326-8ae1-5392-57d8-7054c454cdab&t=bf55eb97-8c00-5287-3ece-aba70d92322c&l=8299
Reproduces how often: [What percentage of the time does it reproduce?]
Always
Versions
mocha --version
andnode node_modules/.bin/mocha --version
: 8.2.0node --version
: Tried locally with v13.12.0 and CI (v10)Additional Information
Downgrading mocha to 8.1.0 solves the issue
The text was updated successfully, but these errors were encountered: