Timeout happening too early

I’m reporting the case from this SO question:

The following example times out in most cases (outputs timed out):

Promise = require('bluebird');

new Promise(resolve => {
    setTimeout(resolve, 1000);
})
    .timeout(1001)
    .then(() => {
        console.log('finished');
    })
    .catch(error => {
        if (error instanceof Promise.TimeoutError) {
            console.log('timed out');
        } else {
            console.log('other error');
        }
    });

Does this mean that the Bluebird’s promise overhead takes longer than 1ms? I see it often time out even if I use .timeout(1002).

---

Using Bluebird 3.5.0, under Node.js 8.1.2

I would expect this to never output timed out, since the timeouts happen in order, and the latter with higher timespan value. Given that the promise chain resolution happens in the microtask queue, the fulfillment callback should log finished before the macrotask timer callback from .timeout() runs and even get a chance at cancelling the promise.

Is this a bug, or are my expectations off?

[benjamingr]

@sanji-programmer Node timers are not accurate to the millisecond fwiw. There is an open bug for that I can hunt it if it’s important to you.

[sanji-programmer]

I can confirm that the fix 892286b can avoid the race reported by @bergus; I could reproduce the race with a tool I’ve worked with to test different schedules of the event loop.

Nevertheless, if we do the opposite:

const Promise = require('bluebird');

new Promise(resolve => {
    setTimeout(function timeout() { resolve() }, 1001);
})
    .timeout(1000)
    .then(function then() {
        console.log('finished');
    })
    .catch(function catch_(error) {
        if (error instanceof Promise.TimeoutError) {
            console.log('timed out');
        } else {
            console.log('other error');
        }
    });

the race remains with this code giving ‘time out’ or ‘finished’ based on the status of event loop.

It seems that, at least in Node, callback timeout() in this code and callback timeoutTimeout() in timers.js are registered in the same tick of event loop; so some order between them can be defined. The issue may be that this.drainQueues() (line 16 of async.js) is registered using setImmediate() and it can race with the other timeout callbacks.