Nodejs does not wait for promise resolution - exits instead

[ddeath]

• Version: v10.6.0
• Platform: Linux 4.15.0-24-generic GitHub issue management #26~16.04.1-Ubuntu SMP Fri Jun 15 14:35:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
• Subsystem:

The code bellow will end with output:

Looping
before
working

and then it ends. The expected output is:

Looping
before
working

and the node should not exit

function sleep(ms) {
    return new Promise((resolve) => { setTimeout(resolve, ms) })
}

class TestClass {
    async processData(data) {
        return new Promise((resolver, rejecter) => {
            console.log('working')
        })
    }
}

class RunnerClass {

    async start() {
        const instance = new TestClass()
        while (true) {
            console.log('Looping')
            if (true) {
                try {
                    console.log('before')
                    const processedData = await instance.processData('data')
                    console.log('after')
                } catch (error) {
                    console.log('errored')
                }
            }
            await sleep(1000)
        }
    }
}

async function run() {
    const rebalancer = new RunnerClass()
    await rebalancer.start()
    console.log('end')
}

run()

If the if statment is set to if (false) then the process is outputting:

Looping
Looping
Looping
...

and never ends...

[vsemozhetbyt]

If I am not mistaken, Node.js does not wait for ever-pending Promises:

'use strict';

(async function main() {
  await new Promise((resolve) => { console.log(42); });
})();

42
[exit]

[vsemozhetbyt]

Refs:
https://stackoverflow.com/questions/46914025/node-exits-without-error-and-doesnt-await-promise-event-callback
https://stackoverflow.com/questions/46966890/what-happens-when-a-promise-never-resolves

[jiripospisil]

If I am not mistaken, Node.js does not wait for ever-pending Promises

In other words, the mere existence of a Promise won't keep the process alive. You actually need to put something on the event loop (e.g. create a timer in the processData method).

By the way, even if the process stayed alive because of some other I/O, I think the expected output would be

Looping
before
working

because the promise Executor is invoked imediately.

[apapirovski]

The answers above are correct. Going to close this out.

[ddeath]

@jiripospisil yes you are right, I edited issue. Of course that working is expected too.

@apapirovski but why the node end the process in the middle of nowhere? It has other code to execute after that await.

There is console.log('end') on the end. In this case I would expect that the process will throw en error or exits with some kind of error.

[ddeath]

For example:

'use strict';

(async function main() {
  await new Promise((resolve) => { console.log(42); });
  console.log(`
    This will never be executed is this expected?
    Also node exits as everything is ok with exit code 0...
  `);
})();

[jiripospisil]

I agree it's a bit weird when you encounter it for the first time (and I have certainly been bitten by this in the past) but the way to think about it is that when you await something, V8 jumps out of the current function (I believe it's implemented as syntax sugar on top of generators, or at least that's the high level idea). At this point Node.js doesn't care about the function anymore and checks whether there are some pending tasks on the event loop. If not, it exits. If you did this instead:

await new Promise((resolve) => { console.log(42); setTimeout(resolve, 2000) });

then Node.js would see there's a timer and stayed alive. When the timer goes off, Node.js invokes the callback and V8 jumps back to the place from which it jumped out off and starts executing the rest of the function.

[Dzenly]

Maybe we could have warning: "Process is exited, but you have pending promises, created on the file:xxx:yyy". But of course if will require some Promise manager and must be optional, just for debug.

[tbranyen]

This bit me pretty hard and has been extremely difficult to understand the behavior implications. I have a bundler which operates in a giant async Promise chain. Once a task completes it moves on to the next. I've added the ability for "loaders" to pre-process an AST and wanted to use a browserify plugin. I wrote the following code:

      transform: async ({ state, source }) => {
        return new Promise((resolve, reject) => {
          const stream = combynify(state.path, {});

          stream.on('data', console.log);

          stream.resume();
          stream.on('finish', function(d) {
            resolve(d);
          });

          stream.on('error', err => reject(err));
        });

This is injected into the Promise chain. Since I'm doing something wrong in this code, there is nothing on the event loop and immediately after this code executes, my bundler dies. This seems incredibly bad for an end user. How would they know what was wrong when they write such a loader? My bundler exits with no errors, exit code 0, and exits in the middle of this giant promise chain.

Should it be my bundlers responsibility to set a huge long timer before any loader, and once the loader is done, call clearTimeout?

[tbranyen]

This is how I've been able to "solve" the problem from my bundler's perspective:

    if (loaderChain.length) {
      const warningTimer = setTimeout(() => {
        console.log('Loader has not resolved within 5 seconds');
      }, 5000);
      const timer = setTimeout(() => {}, 999999);

      code = await handleTransform({ code, loaderChain });

      clearTimeout(timer);
      clearTimeout(warningTimer);
    }

[devsnek]

@tbranyen as long as the stream you wrap is doing things it will work. if the stream absolutely stops but doesn't end or error, nothing will be keeping the process open anymore.

[tbranyen]

@devsnek I believe I covered that in my initial comment:

Since I'm doing something wrong in this code, there is nothing on the event loop and immediately after this code executes, my bundler dies.

The point here is that something was wrong, and given that everything in the chain was a Promise which either resolves, rejects, or hangs, this behavior feels out-of-place. If you were using my tool and there was no indication that the loader was successful or not (since it never resolves or rejects), and the tool simply dies with a non-error exit code, that's pretty bad for debugging. In a browser, Promises can just hang indefinitely since there is no "process" to close in the web page. In Node, I can see how this behavior is ambiguous since there is a distinction made in Node as to whether v8 or libuv scheduled events determine if the Node process is out of work or not.