The upside is it helps notice the problem

Also mentioned is that using sleep inside the for await, does not cause any issues either.

So seems strange that reading lines should. And it's certainly more than just missed lines.Īlso in SO question, switching to using pure streams does not cause any issues. Do you want to open a PR to implement I think the worst thing about this, is that no error is shown, the process just terminates, even try catch or finally will not pick this termination up either. It sounds like you were expecting the latter, and yes I agree that would be a reasonable behavior. I think each proposal makes sense in its own way, so it's only a matter of finding the one that correspond to the expected behavior for most users. return a finished async iterator: the loop would not run at all, and the rest of the code would directly be executed.return a rejected promise: that might help notice the problem even more, but is also annoying to have to wrap the loop in a try/ catch block.return a never resolving promise (current behavior): the upside is it helps notice the problem, without raising any exception.I can think of three ways of handling that situation: I don't think it 'ignores' it, it deals with it. Ignoring that the stream is already closed. mjs file, as the exit code for the program is set to 13 instead of 0. it's more obvious if you use top-level await in a.

That's correct, it's effectively waiting for a 'line' event, which indeed will never happen. Why does it not print ' DONE' in the end? It's as if the () method waits for an event that will never be fired

Node js sleep await