`close` being emitted without `end` or `error`

Nobody has claimed this yet.

It's possible that I'm misunderstanding, but I'm working with tar-fs, which I understand depends on streamx, and I have a case where (intermittently), I'm seeing a `close` event fire on a tarStream, but `error` never fires and neither does `end`. This actually ends up causing the script to hang (presumably because the consumer is waiting for an `end` event that it will never get, now that `close` has emitted).

Am I correct in thinking that (generally), `close` should not be firing before `end` in most "normal" cases? And if it does, it means something has probably gone wrong (forcibly closed the stream?). But if that's the case, shouldn't the `close` event pass in an error object? Or shouldn't there ALSO have been an `errror` event emitted? I get neither, so it's incredibly difficult to find the root cause.

Any insight would be appreciated. Unfortunately, the code where I'm seeing this happen is large and complex, and I don't (yet) have any easy way to extract out a simple repro. I will of course, update this issue if I'm able to provide code that repros.

In the meantime, I was just hoping to get some general insight on how streamx fundamentally works (or is supposed to work) from the author.

No source file, test, or minimal reproduction is provided. Start by tracing streamx's close, end, and error event semantics and reduce the tar-fs case to a reproducible test; done means establishing the expected event sequence and either documenting it or identifying a concrete fix.

Written by the indexing model from the issue text.