Repository navigation
streams: non-writable Duplex is writable (more annoyance than bug) #34374
Description
Activity
Also, just to be thorough, the same issue exists with
readable: falseand the readable side. Specifically:const d = new stream.Duplex({ readable: false, read() { this.push(Buffer.from('abc')); this.push(null); } }); console.log(d.readable); // false d.setEncoding('utf8'); d.on('data', console.log); // prints abc
What would you like to happen? Error if write/push to a non writable/readable stream?
readable/writable false should be as if end()/push(null) has been called in the constructor but without emitting the associated events?
@ronag @jasnell
Correct me if I am wrong here, according to the readable.readable and writable.writable docs they must be used to check if it is safe to read/write on the stream. That's why settingwritableandreadableexplicitly doesn't seem to work, maybe that's the reason we don't get the option to setwritableandreadableproperty as options while creating a newDuplex.
However if I am wrong, the ideal behavior that is throwing an error as proposed by @jasnell looks good.Correct me if I am wrong here, according to the readable.readable and writable.writable docs they must be used to check if it is safe to read/write on the stream
No, they don't need to be checked. Calling it "safe" is maybe a bit misleading, but the following sentence does explain what it means in the context.
That's why setting writable and readable explicitly doesn't seem to work
It does "work". Depends on what you mean by "works". Though that usage is deprecated.
maybe that's the reason we don't get the option to set writable and readable property as options while creating a new Duplex.
That option actually does exist and should be used. It's just not documented, which we should fix.
It does "work". Depends on what you mean by "works". Though that usage is deprecated.
By "doesn't work" I meant that we are allowed to read/write on a non readable/writable
DuplexThat option actually does exist and should be used. It's just not documented, which we should fix.
Should I open another issue regarding this? Also are there any more options other than
writableandreadablethat must be included in the docs?Should I open another issue regarding this?
Sure!
Also are there any more options other than writable and readable that must be included in the docs?
I don't think so.
Reacted by Priyank Singh- added a commit that references this issue
on May 22, 2026
@mcollina @ronag @nodejs/streams
This isn't a bug since it's been like this forever but the behavior is really counter intuitive, especially since after calling
d.end()and then doing ad.write()we get a properwrite after enderror. It makes implementing a customDuplex(e.g.QuicStream) more difficult because of the additional checks that need to be made to ensure that even tho theDuplexisn't writable no-one is writing to it.Not sure what the fix is immediately but wanted to discuss it first.
The ideal behavior, I would think, is an error similar to
write after endifwrite()is called on a non-writableDuplex.