Confused setTimout behaviour in NodeJS

[jakecastelli]

Version

14, 18

Platform

22.2.0 Darwin Kernel arm64

Subsystem

No response

What steps will reproduce the bug?

setTimeout(() => {
  console.log('calling 1st timeout')
}, 1)

setTimeout(() => {
  console.log('calling 2rd timeout')
}, 0)

// in nodejs
// calling 1st timeout
// calling 2rd timeout

// however, in chrome browser
// calling 2rd timeout
// calling 1st timeout

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

Would expect the second time to be called first

What do you see instead?

The first time out is called then the second timeout in NodeJS

Additional information

No response

[bnoordhuis]

That's working as designed. From the timers documentation:

When delay is larger than 2147483647 or less than 1, the delay will be set to 1.

The WHATWG spec leaves some wiggle room ("This API does not guarantee that timers will run exactly on schedule") so some variation between implementations is to be expected.

Node could be changed to behave more like Chrome but there's a non-zero risk of ecosystem fallout.

[jakecastelli]

@bnoordhuis Thanks for clarifying it Ben!
I found even node 14 and node 18 behave a little bit different as well with the following code snippet.

for example:

setTimeout(() => {
  console.log('calling 1st timeout')
}, 3)

setTimeout(() => {
  console.log('calling 2rd timeout')
}, 2)

in node 14 it will be:

calling 1st timeout
calling 2rd timeout

however in node 18 it will be

calling 2rd timeout
calling 1st timeout

I guess there is no practical use case for the above in any event but just something I found interesting and not really documented somewhere.

[BridgeAR]

I am in favor of changing the behavior for 0 to behave as chrome does.

Besides that, I would actually like to deviate from the spec when it comes to exceeding 2147483647. It is not user friendly at all to just change the timing to a lower number due to the overflow. Instead, we could either accept numbers up until Number.MAX_SAFE_INTEGER and or throw above that limit. It is otherwise pretty much impossible to detect these faulty values.

[cjihrig]

I agree completely that the behavior in the spec is not good, but I don't think we should deviate from it.

[jasnell]

Changing the timing of this stuff always carries a non-zero risk of breaking apps. While the inconsistency with browsers is unfortunate, I agree that we likely shouldn't change it.

[bnoordhuis]

Perhaps someone wants to open a pull request and run it through citgm to get a feel for how bad it impacts the ecosystem?

[mcollina]

I don't think we should deviate from the spec. I could be convinced if this would cause no ecosystem breakage.

[jakecastelli]

Wanna point out the code blow in chrome browser does not set the delay to 1 which is a little bit surprising.

setTimeout(() => {
  console.log('finished')
}, 100000000000000)

[jakecastelli]

@bnoordhuis Thanks for clarifying it Ben! I found even node 14 and node 18 behave a little bit different as well with the following code snippet.

for example:

setTimeout(() => {
  console.log('calling 1st timeout')
}, 3)

setTimeout(() => {
  console.log('calling 2rd timeout')
}, 2)

in node 14 it will be:

calling 1st timeout
calling 2rd timeout

however in node 18 it will be

calling 2rd timeout
calling 1st timeout

I guess there is no practical use case for the above in any event but just something I found interesting and not really documented somewhere.

Is it possible to discuss the above in tsc agenda meeting as well (despite it is mentioned in the doc - The callback will likely not be invoked in precisely delay milliseconds. Node.js makes no guarantees about the exact timing of when callbacks will fire, nor of their ordering. The callback will be called as close as possible to the time specified.), looks like there is a behaviour change in node v18.x in comparison to previous node versions but it is not being mentioned in the doc history.

[mcollina]

There is no behavior change, timers are weird for this and they highly depend on the event loop phases, the startup time of Node.js and the underlining operating system.

[BridgeAR]

The standard itself does actually not provide any restrictions when it comes to zero being handled as one or the maximum value being a 32-bit signed integer. The latter seems to be a historic implementation detail of browsers while not ending in the spec itself.
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout

I suggest to split the discussion into three parts:

1. How to handle zero (the spec only defines to set the value to zero in case the value is below zero)
2. What to do with timers set above 2 ** 32? (the spec does not provide any limit)
3. How to handle nesting level as defined by the spec. It is optional as it seems and we do not implement this.

[bnoordhuis]

What to do with timers set above 2 ** 32? (the spec does not provide any limit)

For the record, node follows what browsers did ca. 2011: nodejs/node-v0.x-archive#593 (comment)