feat: set global timeout in command line argument #8456
Conversation
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed. If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks! |
ert78gb
force-pushed
the
feat-timeout-in-command-line-arg
branch
from
335d649
to
d36815c
Compare
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
|
Hey @ert78gb, thanks a lot for tackling one of the most +1ed issues :) |
|
Hi @jeysal I will check soon what is in the "circus" :) |
|
I solved the Maybe would be better if I create an initState function but currently, I recognized only the timeout parameter to pass and the modified file is in the todo-rewrite folder, so when you will rewrite this part of the code I think you will find a better place to initialize the global timeout. |
Codecov Report
@@ Coverage Diff @@
## master #8456 +/- ##
==========================================
+ Coverage 60.56% 60.56% +<.01%
==========================================
Files 269 269
Lines 11045 11051 +6
Branches 2690 2694 +4
==========================================
+ Hits 6689 6693 +4
- Misses 3770 3772 +2
Partials 586 586
Continue to review full report at Codecov.
|
| @@ -789,6 +790,11 @@ export default function normalize( | |||
| value = oldOptions[key]; | |||
| break; | |||
| } | |||
| case 'timeout': { | |||
| value = | |||
| oldOptions[key] === 0 ? MAX_32_BIT_SIGNED_INTEGER : oldOptions[key]; | |||
There was a problem hiding this comment.
can we throw if it's 0? I bet 99.99% of the time, that's not what the user wanted.
Should throw if it's <= 0
There was a problem hiding this comment.
Maybe even throw if it's more than, say, an hour. I don't see there being any use case for more than an hour, and again, I'd guess it was some calculation gone wrong for the user
There was a problem hiding this comment.
I would like to use 0 to represent the infinity timeout. Similar to other test frameworks. I want an infinity timeout when I debugging. I agree most of the time 10 min is more than enough, but there is a few edge case when need an hour.
jasmine always need a DEFAULT_TIMEOUT_INTERVAL value this is the reason why I set it. I use the max possible 32 bit signed value because I would like to avoid the next issue about pls increase the value x+1.
I can implement the <0 error throwing.
There was a problem hiding this comment.
@SimenB What is the final statement about the setTimeout = 0 and max value? I would like to implement them in 1 comment
There was a problem hiding this comment.
What I'm afraid of is somebody messing up their math or something and having ci use a bajillion years timing out.
I'd rather have -1 mean infinity, 0 seems like a math error to me. I might be alone in that though :)
There was a problem hiding this comment.
Why not just require a positive sign number or Infinity.
You can check on infinity and return MAX_32_BIT_SIGNED_INTEGER for jasmine.
Meaning 0 would be instant timeout?
This might be weird for users if other test frameworks default on the 0 = no timeout behaviour.
There was a problem hiding this comment.
Is there intentional precedence or just what I'd consider buggy code if (timeout) {setSomeTimeout()} since 0 is falsy? Seems more natural to be explicit using the Infinity global. That doesn't really translate to json or CLI config, though...
I don't feel too strongly here if making 0 mean infinity is something mocha, jasmine, tap, ava or someone else already does
There was a problem hiding this comment.
- mocha, tap use 0 to represent infinity timeout
- jasmine need a positive integer. max 2^32-1 the possible value.
Infinityis not option for jasmine - ava has not got default timeout
I am using mocha near 6 years and I never make mistake when I switch off the timeout.
All modern CI listen to /read from the standard output and if no message - mostly in 10 min - it stop the build process.
If everyone search for the option to switch off the timeout then he/she will read the documentation and if 0 is the no timeout option will use it.
I think the current solution 0 = no timeout is match with the industry standard. Jasmine need an exact value so we need to translate the 0 to a big value. The biggest value 2^32-1.
It's up to you what will the final solution, but pls don't overthink a simple problem :)
|
Hello, any chance of getting this PR merged, seems like the requested changes are minor? |
|
I will do the changes asap if we agree in the final solution. But I have not receive any answer 9 days |
|
I have all but strong feelings about the meaning of 0 here, which is why I didn't comment on this earlier. Do we have to treat it in a special way at all? What happens if we don't? In my mental model, the config option works by running the test this way: setTimeout(() => cancelTestIfStillRunning(), config.timeout);
await runTestToCompletionOrCancellation();So if the test is synchronous or only uses microticks, it's fine. And a timeout of 1ms seems no less absurd than 0 to me, so why forbid one but not the other. |
ert78gb
force-pushed
the
feat-timeout-in-command-line-arg
branch
from
4488cb9
to
2ea81b9
Compare
|
I renamed the |
|
@jeysal You are right in synchronous tests but, this problem is not related to this issue |
|
I'd just not treat any numbers in a special way for reasons described in my latest comment and because it's what
Do we absolutely need one? I'm with @SimenB on this, just use |
|
Ok, then I will remove the special meaning of the 0 and I will add testTimeout < 0 validation |
|
I removed the 0 special meaning. |
packages/jest-circus/src/legacy-code-todo-rewrite/jestAdapterInit.ts
Outdated
Show resolved
Hide resolved
|
I think I finished. |
|
when will this be released to NPM? |
|
When we make a release (no timeline). We try to prioritize bug fixes, but features are bound to whenever a release happens. However, we'll probably have one last 24 release soonish (again, no timeline) |
|
You should fix syncing the docs on the website with the npm releases. When I go to Jest CLI Options it lists the |
|
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. |
Summary
My motivation is. When I debug the unit tests in IntelliJ and I got a timeout error.
Other's motivation: #6216
I would like to set the timeout to Infinity when jest runner in debug mode if this PR is approved. I like the step by step development
Test plan
I extended the timeout e2e tests with use cases