-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
http.ServerResponse is not an instance of stream.Writable? #44188
http.ServerResponse is not an instance of stream.Writable? #44188
Comments
Throwing an error here seems to be an expected behavior since
|
It seems that the bug is on @types/node class OutgoingMessage extends stream.Writable { Of course, the @daeyeon proposition is successful.
|
|
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 :) |
Attempted to fix the issue by watering down the condition being checked in lib/internal/webstreams/adapters.js similar to isWritableNodeStream utility being used in internal/streams/utils Fixes: nodejs#44188
Attempted to fix the issue by watering down the condition being checked in internal/streams/utils isWritableNodeStream utility Fixes: nodejs#44188
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? |
… instead of stream http.OutgoingMessage is supposed to be an instance of stream.Writable, so I set the prototype of OutgoingMessage equal to the Writable prototype and I called the Writable consrtuctor at the end of the constructor for OutgoingMessage. I made sure to override any methods and prpoperties in Writable that were already defined in OutgoingMessage in order to not interfere with the current behavior of OutgoingMessage. Fixes: nodejs#44188
@zeazad-hub FWIW, there seems to be a performance issue when trying |
Attempted to fix the issue by watering down the condition being checked in internal/streams/utils isWritableNodeStream utility Fixes: #44188 PR-URL: #45642 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]>
Attempted to fix the issue by watering down the condition being checked in internal/streams/utils isWritableNodeStream utility Fixes: nodejs#44188 PR-URL: nodejs#45642 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]>
Attempted to fix the issue by watering down the condition being checked in internal/streams/utils isWritableNodeStream utility Fixes: #44188 PR-URL: #45642 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]>
… instead of stream http.OutgoingMessage is supposed to be an instance of stream.Writable, so I set the prototype of OutgoingMessage equal to the Writable prototype and I called the Writable consrtuctor at the end of the constructor for OutgoingMessage. I made sure to override any methods and prpoperties in Writable that were already defined in OutgoingMessage in order to not interfere with the current behavior of OutgoingMessage. Fixes: nodejs#44188
I accidentally left a script.sh file that copied all of the test files into a different directory in a previous commit. I did not end up using the script.sh and have now removed it from the repo. Fixes: nodejs#44188
Attempted to fix the issue by watering down the condition being checked in internal/streams/utils isWritableNodeStream utility Fixes: #44188 PR-URL: #45642 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]>
Attempted to fix the issue by watering down the condition being checked in internal/streams/utils isWritableNodeStream utility Fixes: #44188 PR-URL: #45642 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]>
Attempted to fix the issue by watering down the condition being checked in internal/streams/utils isWritableNodeStream utility Fixes: #44188 PR-URL: #45642 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]>
Attempted to fix the issue by watering down the condition being checked in internal/streams/utils isWritableNodeStream utility Fixes: #44188 PR-URL: #45642 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]>
Attempted to fix the issue by watering down the condition being checked in internal/streams/utils isWritableNodeStream utility Fixes: #44188 PR-URL: #45642 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]>
Attempted to fix the issue by watering down the condition being checked in internal/streams/utils isWritableNodeStream utility Fixes: #44188 PR-URL: #45642 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yagiz Nizipli <[email protected]>
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
ServerResponse
fulfilling 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?
The text was updated successfully, but these errors were encountered: