Repository navigation
http.ServerResponse is not an instance of stream.Writable? #44188
Description
Activity
- addedhttpIssues and PRs related to the http subsystem.Issues and PRs related to the http subsystem.
on Aug 9, 2022 http.ServerResponse is not an instance of stream.Writable?
Throwing an error here seems to be an expected behavior since
http.ServerResponseis an instance ofStream, notstream.Writable. Is this issue a feature request for the following?stream.Writable.toWeb(stream : <stream.Writable>|<http.OutgoingMessage>)
- addedstreamIssues and PRs related to Node.js streams.Issues and PRs related to Node.js streams.web streamsIssues and PRs related to the Web Streams API.Issues and PRs related to the Web Streams API.
on Aug 14, 2022 It seems that the bug is on @types/node
class OutgoingMessage extends stream.Writable {
Of course, the @daeyeon proposition is successful.
stream.Writable.toWeb(stream : <stream.Writable>|<http.OutgoingMessage>)
- addedconfirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.
on Nov 4, 2022 toWebshould work onOutgoingMessage.- addedgood first issueIssues that are suitable for first-time contributors.Issues that are suitable for first-time contributors.
on Nov 4, 2022 Has anyone claimed this issue? I haven't contributed before but I think this would be a good first issue for me as I have some ideas on a fix.
Was this issue already assigned? If not, I'd like to try and solve it. Thanks.
go for it :)
Hey, is this issue still open, because I would like to work on it as my first issue.
Hello, I found out what was going wrong. Our outgoing message defined here does not extend stream.writable. The probelm is that stream.writable has a writable attribute that behaves differently from the OutgoingMessage writabel attribute and this causes test/parallel/test-http-writable-true-after-close.js to fail because it is not writable after it is destroyed. I was wondering if OutgoingMessage.writable should be true when OutgoingMessage.destroyed is true (like the test checks for) or should OutgoingMessage.writable be false when it gets destroyed?
- added a commit that references this issue
on Dec 8, 2022 @zeazad-hub FWIW, there seems to be a performance issue when trying
OutgoingMessageinheritingstream.Writable.- added a commit that references this issue
on Dec 10, 2022 - added a commit that references this issue
on Dec 12, 2022 - added 2 commits that reference this issue
on Dec 12, 2022 - added a commit that references this issue
on Dec 13, 2022
Version
18.7.0
Platform
Microsoft Windows NT 10.0.19044.0 x64
Subsystem
stream
What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
Always.
What is the expected behavior?
According to the documentation:
This means that
ServerResponsefulfilling the contractWritable.toWeb.What do you see instead?
TypeError [ERR_INVALID_ARG_TYPE]: The "streamWritable" argument must be an stream.Writable. Received an instance of ServerResponse at new NodeError (node:internal/errors:387:5) at Object.newWritableStreamFromStreamWritable (node:internal/webstreams/adapters:99:11) at Writable.toWeb (node:internal/streams/writable:926:27)Additional information
Maybe this condition:
is too heavy?