Node: setInterval setTimeout break for interval > 2^32-1

[davidhadas]

• Version: v6.11.2
• Platform: tested on linux and mac
• Subsystem:

 setInterval(()=>{console.log("a");}, Math.pow(2,31));

same for:
setTimeout(()=>{console.log("a");}, Math.pow(2,31));

Timeout is fired as if it is:
setInterval(()=>{console.log("a");}, 0);
or
setTimeout(()=>{console.log("a");}, 0);

The same issue with any timeout or interval > Math.pow(2,31)-1

Should raise an exception instead.

[mscdex]

I'm pretty sure this was done to match browser behavior. If you test the same code in Chrome for example, you will see the same behavior.

[davidhadas]

no reason to match a bug...
If browsers also behave this way, they need to be fixed.

The consequences of this can take down systems as programmers do not expect this behavior.

[mscdex]

When it comes to browser-y APIs, node tries to match behavior and interfaces as much as possible to accommodate web developers and existing code.

[mscdex]

Additionally, the WHATWG HTML spec currently specifies the timeout value as being a long type and WebIDL defines long as having a range of −2147483648 to 2147483647.

[bnoordhuis]

The consequences of this can take down systems as programmers do not expect this behavior.

I'm the author of that change in Node.js and I added it because people reported it as a bug: the fact that Node.js didn't match the browser was confusing to them.

I'm closing this out. It's been discussed a couple of times over the years and I don't see us changing it.

[kapouer]

As you can see, every 25 days there is going to be someone complaining about that bug (which should be fixed in browsers as well). I propose to automate the reporting until the bug is fixed:

function task() {
  reportBugAboutInterval().then(function() {
    setTimeout(task, 25 * 24 * 60 * 60 * 1000)
  })
})

What could possibly go wrong with that code ?

[apapirovski]

@kapouer If I want to set my timeout to fire every 2^50 and instead it gets capped to the max then that behaviour is even more confusing and hard to discover than if it just fires after 1ms. The latter, in addition to the warning, immediately lets me know that my code is incorrect.

(As an example, if I were foolish enough to set timeouts for my billing, I would start billing my customers every 25 days instead of every 30 days like my app is intended to do. I wouldn't even have a chance to discover this bug in dev environment before deploying it.)

[kapouer]

Then i suppose the only correct behavior would be to throw an exception.

[apapirovski]

@kapouer Perhaps but that would need to be tackled at the standards level at this point. Given the high likelihood of breaking existing code, I can't imagine that will actually ever come to pass.

See https://html.spec.whatwg.org/#dom-settimeout

[BridgeAR]

We added a warning in newer versions against this. So it can at least be detected easier.

@apapirovski in what way do you think it will break existing code if you throw in those cases? If the timeout is triggered right away in those cases it is of course also an error, so I highly doubt that anyone is actually relying on that behavior?

[apapirovski]

@BridgeAR I just know that WHATWG and the implementers are generally very cautious about changing long-standing behaviour like this. (It's not like they haven't ever received bug reports about it.)

In terms of what it would break — obviously executing a timeout immediately has different implications than throwing an error. An app that performs some operation every 1ms is still functional, even if it's not doing what it's intended to. Throwing an error means it won't execute the callback at all, making it truly broken.

(If I'm really being asked to come up with an example... Imagine I have a front-end interface that uses setInterval to update the month displayed. Right now it triggers every 1ms but it still means the app works as intended, despite likely consuming unnecessary CPU cycles. Going forward it might not work at all, depending on how my code is written and whether any other JS executes within the same operation as setting the interval.)