- Version: v16.1.0
- Platform: Darwin Kernel Version 20.3.0
- Subsystem: stream
What steps will reproduce the bug?
let { PassThrough, finished } = require("stream");
let stream = new PassThrough();
stream.destroy();
stream.on("close", function()
{
finished(stream, err => console.log(err));
});
How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior?
Maybe it should produce an error like ERR_STREAM_PREMATURE_CLOSE (or ERR_STREAM_DESTROYED). But I would strongly prefer ERR_STREAM_PREMATURE_CLOSE (in fact this is form of premature close) because this error is returned when the stream is destroyed after the call to finished and before finished calls its callback. This would be much more consistent than race between two different errors based on when exactly the stream was destroyed. It just complicates code path which tries to react to this situation and is unaware whether the stream is already destroyed or not (it would have to check for two error codes instead of only one). Same should be done for the pipeline #36674.
What do you see instead?
Promise version resolves.
Additional information
What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior?
Maybe it should produce an error like
ERR_STREAM_PREMATURE_CLOSE(or. But I would strongly preferERR_STREAM_DESTROYED)ERR_STREAM_PREMATURE_CLOSE(in fact this is form of premature close) because this error is returned when the stream is destroyed after the call tofinishedand beforefinishedcalls its callback. This would be much more consistent than race between two different errors based on when exactly the stream was destroyed. It just complicates code path which tries to react to this situation and is unaware whether the stream is already destroyed or not (it would have to check for two error codes instead of only one). Same should be done for thepipeline#36674.What do you see instead?
Promise version resolves.
Additional information