Readables that close without an 'end' event does not end.

[Flygsand]

Consider the following code:

function readFile(name) {
  return _(fs.createReadStream(name));
}

var extra = _([new Buffer('baz')]);

_(['foo', 'bar'])
  .map(readFile)
  .merge()
  .concat(extra)
  .errors(function() { })
  .each(_.log);

If both foo and bar are successfully read, the stream produces three buffers (contents of foo, contents of bar, and extra). If, for example, bar can't be read, the stream produces one buffer (contents of foo). Wouldn't it make more sense for the stream to produce (contents of foo, and extra) in that case?

[vqvu]

You have a knack for finding bugs in our code 😄.

This isn't a concat thing. The fs.createReadStream will close itself when it encounters an error. This means emitting close without emitting end. We weren't listening to the close event, so the wrapper stream thought that the stream had never ended. That's why you didn't see the data from extra. It was waiting for the original foo/bar streams to end and they never did.

[Flygsand]

Ah :). Kudos again for the quick turnaround.

[vqvu]

I take back what I said above. In the case where you try to open an non-existent file, you don't end getting a close at all. You just get a single ENOENT error. close only fires if the file was successfully opened but there was an error reading from it. Same class of bug though.