jest.setTimeout doesn't respect really long timeout settings

[JayAndCatchFire]

🐛 Bug Report

jest.setTimeout doesn't respect ridiculously large numbers.

To Reproduce

Either in a setup script or in a test, add jest.setTimeout(Number.MAX_SAFE_INTEGER); and run an asynchronous test that either takes a while or never returns.

When running the test, it fails with the message Timeout - Async callback was not invoked within the 9007199254740991ms timeout specified by jest.setTimeout. (in the case of Number.MAX_SAFE_INTEGER).

That's 285 millennia and change. Obviously I didn't wait that long. In fact, I waited the default 5000ms or possibly less for it to throw this error.

The reason I did this in the first place was because I didn't see any way to turn off test timeouts completely and I had a test that was taking longer than 5000ms. I knew my test would complete eventually and I was curious how long it would take. So I set the timeout to Number.MAX_SAFE_INTEGER.

In the end, I was able to see how long my test took to complete by giving it an absurdly long wait time that was less than Number.MAX_SAFE_INTEGER.

Expected behavior

I expect Jest to either throw an error or warning saying that length of time is too long and then ignore my setting _or_ actually wait for 9007199254740991ms.

Run npx envinfo --preset jest

Paste the results here:

System:
    OS: macOS 10.14.2
    CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
  Binaries:
    Node: 10.15.1 - ~/.nvm/versions/node/v10.15.1/bin/node
    Yarn: 1.13.0 - /usr/local/bin/yarn
    npm: 6.7.0 - ~/.nvm/versions/node/v10.15.1/bin/npm

[JayAndCatchFire]

FYI, the number I ended up using that worked was a 1 with a fair number of zeros after it. I just tried doing the test against jest.setTimeout(Number.MAX_SAFE_INTEGER - 2); to see if it was something special about Number.MAX_SAFE_INTEGER and it similarly timed out almost immediately.

[jeysal]

This behavior likely comes from global.setTimeout itself. Running
setTimeout(()=>console.log('asdf'),Number.MAX_SAFE_INTEGER) in the Node REPL gives

(node:35121) TimeoutOverflowWarning: 9007199254740991 does not fit into a 32-bit signed integer.
Timeout duration was set to 1.
asdf

[SimenB]

Sounds like jest should throw on too high timeouts, then?

[jeysal]

Could perhaps do that, but I think the real question is: Why is the warning swallowed? If we can avoid that, we could possibly get a full class of potential warnings from edge cases in Node API usage to show up instead of being lost.

A plain setTimeout in your test does show you the TimeoutOverflowWarning.
I guess callAsyncCircusFn is where the jest.setTimeout arrives? (For circus)