-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Prevent false test failures caused by promise rejections handled asynchronously #14315
Prevent false test failures caused by promise rejections handled asynchronously #14315
Conversation
✅ Deploy Preview for jestjs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi again, @stekycz! could you resolve the conflict and add a changelog entry? 🙂
…ons handled asynchronously (jestjs#14110)" (jestjs#14304)" This reverts commit 208f2f1.
100d8ed
to
bf1bae4
Compare
@SimenB Thanks for pinging me. I have just rebased the revert of the revert commit and added the changelog entry. Pls, let me know if there is anything else I can do. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
CI is unhappy here. Probably that the |
@SimenB I am looking into it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
Hey @stekycz! I was looking into another issue, and found that this PR has a quite bad performance hit. If you clone https://github.com/luiz290788/jest-node-16, you can see. db42fe5 is the merge commit of this PR.
The tests in that reproduction run horribly slow. Easiest way to test with a local version of jest is just (from within that repo)
And the tests are fine. |
Ping @stekycz - I might have to revert this again unless we can get to the bottom of it 😬 |
@SimenB I am sorry, I have been off a few days and I finally got to this. I am not sure what exactly is causing the performance issue but I will try to find the root cause this week. Once I know what is causing it, the best solution would probably be hide this feature under a flag, similar to |
Sounds like a good plan, thanks @stekycz! |
@SimenB I have spent some time investigating what and why is the slow part. Let me elaborate a bit below. A) The element causing slow down is waiting for the next tick on the event loop. When I commented that code, it was back on times as on the commit before the merge of this PR. However, we cannot simply remove that as we would possibly fall into 2 issues - false positive and false negative. B) The repo you sent me is very artificial having 100k simple and fast tests. All of them are so fast that waiting for the next event loop after each test adds ~1-2ms (on my machine) to each test and it adds up given the amount of individual tests. Based on my experience, projects usually do not have so many tests and when they do, they are not all so fast. Therefore, for the most common usages the slow down would not be significant addition to the existing test execution duration IMO. C) Another ~1-2ms (on my machine) is added to each test because of event loop awaiting after a hook execution. The example repo does not have any hook though. It brought me to a default Based on those findings I believe the case with 100k simple and fast tests can be considered an edge case. For majority of test code bases the slow down should be insignificant. If not, it can be addressed either now or even in a later version (giving us chance to test the feature sooner). I will leave that decision on you. However, fixing it now would not be a simple task IMO so reverting again would be the fastest option. The slow down can be addressed by adding a (CLI) flag for the event loop awaiting. The documentation should mention then about caveats for edge cases I mentioned above in A). The flag can be implemented in 2 ways:
I would prefer option 1) as it is safer for newbies. The option 2) is similar to Pls, let me know what you think about it. I can eventually add the flag for the feature based on your feedback. Thanks! |
Just published https://github.com/jestjs/jest/releases/tag/v30.0.0-alpha.1 which includes this. Thanks for the thorough analysis! I think I prefer option 2 - people already have a perceived notion Jest is slow - adding micro-slowdowns all over won't help that narrative I'm afraid. And when we have the flag, we can always flip the default later 🙂 |
Alright! Thanks for getting back to back to me. What is your runway to release the version |
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This reverts commit 208f2f1.
Original PR #14110
Intended to be part of v30 release as discussed #14110 (comment)