This is part of a larger process that I've distilled down to the minimal, reproducible example in node v14.4.0. In this code, it outputs nothing from inside the for
loop.
I see only this output in the console:
before for() loop
finished
finally
done
The for await (const line1 of rl1)
loop never goes into the for
loop - it just skips right over it:
const fs = require('fs');
const readline = require('readline');
const { once } = require('events');
async function test(file1, file2) {
try {
const stream1 = fs.createReadStream(file1);
await once(stream1, 'open');
const rl1 = readline.createInterface({input: stream1, crlfDelay: Infinity});
const stream2 = fs.createReadStream(file2);
await once(stream2, 'open');
const rl2 = readline.createInterface({input: stream2, crlfDelay: Infinity});
console.log('before for() loop');
for await (const line1 of rl1) {
console.log(line1);
}
console.log('finished');
} finally {
console.log('finally');
}
}
test("data/numbers.txt", "data/letters.txt").then(() => {
console.log(`done`);
}).catch(err => {
console.log('Got rejected promise:', err);
})
But, if I remove either of the await once(stream, 'open')
statements, then the for
loop does exactly what it is expected to (lists all the lines of the rl1
file). So, apparently, there's some timing problem with the async iterator from the readline interface between that and the stream. Any ideas what could be going on. Any idea what could be causing this one or how to work around it?
FYI, the await once(stream, 'open')
is there because of another bug in the async iterator where it does not reject if there's an issue opening the file whereas the await once(stream, 'open')
causes you to properly get a rejection if the file can't be opened (essentially pre-flighting the open).
If you're wondering why the stream2 code is there, it is used in the larger project, but I've reduced this example down to the minimal, reproducible example and only this much of the code is needed to demonstrate the problem.
Edit: In trying a slightly different implementation, I found that if I combine the two once(stream, "open")
calls in a Promise.all()
, that it then works. So, this works:
const fs = require('fs');
const readline = require('readline');
const { once } = require('events');
async function test(file1, file2) {
try {
const stream1 = fs.createReadStream(file1);
const rl1 = readline.createInterface({input: stream1, crlfDelay: Infinity});
const stream2 = fs.createReadStream(file2);
const rl2 = readline.createInterface({input: stream2, crlfDelay: Infinity});
// pre-flight file open to catch any open errors here
// because of existing bug in async iterator with file open errors
await Promise.all([once(stream1, "open"), once(stream2, "open")]);
console.log('before for() loop');
for await (const line1 of rl1) {
console.log(line1);
}
console.log('finished');
} finally {
console.log('finally');
}
}
test("data/numbers.txt", "data/letters.txt").then(() => {
console.log(`done`);
}).catch(err => {
console.log('Got rejected promise:', err);
});
This is obviously not supposed to be sensitive to exactly how you wait for file open There's some timing bug somewhere. I'd like to find that bug on either readline or readStream and file it. Any ideas?
It turns out the underlying issue is that
readline.createInterface()
immediately, upon calling it will add adata
event listener (code reference here) and resume the stream to start the stream flowing.and
Then, in the
ondata
listener, it parses the data for lines and when it finds a line, it fires aline
events here.But, in my examples, there were other asynchronous things happening between the time that
readline.createInterface()
was called and the async iterator was created (that would listen for theline
events). So,line
events were being emitted and nothing was yet listening for them.So, to work properly
readline.createInterface()
REQUIRES that whatever is going to listen for theline
events MUST be added synchronously after callingreadline.createInterface()
or there is a race condition andline
events may get lost.In my original code example, a reliable way to work-around it is to not call
readline.createInterface()
until after I've done theawait once(...)
. Then, the asynchronous iterator will be created synchronously right afterreadline.createInterface()
is called.One way to fix this general issue would be to change
readline.createInterface()
so that it does not add thedata
event and resume the stream UNTIL somebody adds aline
event listener. This would prevent data loss. It would allow the readline interface object to sit there quietly without losing data until the receiver of its output was actually ready. This would work for the async iterator and it would also prevent other uses of the interface that had other asynchronous code mixed in from possibly losingline
events.Note about this added to a related open readline bug issue here.