-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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
RequestInit: duplex option is required when sending a body #46221
Comments
The error is expected, see whatwg/fetch#1457 |
So this happens because Node can't do full duplex when streaming so Ugh, it's gonna break so many things :/ |
I believe it is a changes from specification to force it to be a |
maybe This error occurs because you are passing a ReadableStream as the body of the request without providing the duplex option in the RequestInit object. To fix the error, you can provide the duplex option and set it to true, like this:
This tells the Request constructor that the body is a duplex stream that can both be read from and written to. Note that the duplex option is required when sending a ReadableStream as the body of the request, as stated in the error message. |
just do not forget
|
Why the spec did not just came up with applying the only sane default value to duplex: 'half' (and that is easy, because it's the only actual value at the moment) but instead forcing everybody to insert this options with only one available value is out of my mind. |
Node sneakily introduced a change to the fetch API that now requires that the `duplex` option be set on all requests with contain a payload body: nodejs/node#46221 , which means that the CLI now fails on node >18.13, >19.1, 20, and running the CLI on those versions will cause the following exception: ``` RequestInit: duplex option is required when sending a body. Exited with code exit status 1 ``` This configures all fetch requests with bodies to set the duplex option to the only value that is allowed by the spec for now, which is `"half"`. This should have no impact on older node versions since it's the only option available, but will allow the CLI to run on those newer versions without throwing an error.
Node sneakily introduced a change to the fetch API that now requires that the `duplex` option be set on all requests with contain a payload body: nodejs/node#46221 , which means that the CLI now fails on node >18.13, >19.1, 20, and running the CLI on those versions will cause the following exception: ``` RequestInit: duplex option is required when sending a body. Exited with code exit status 1 ``` This configures all fetch requests with bodies to set the duplex option to the only value that is allowed by the spec for now, which is `"half"`. This should have no impact on older node versions since it's the only option available, but will allow the CLI to run on those newer versions without throwing an error.
# Why - Hitting this issue when invoking server actions using the new req/res system nodejs/node#46221 - Hitting issues with running `tsc` on compiled code. These are caused by importing types from the build directory. Fixed it by duplicating the types to the install.d.ts file. --------- Co-authored-by: Expo Bot <34669131+expo-bot@users.noreply.github.com>
If the body of a request is a stream, we could start receiving the response before the request has been fully sent (full duplex). However, Node does not support full duplex. Since other JS runtimes do support full duplex, Node now requires to pass "duplex: 'half'" for compatibility concerns with those JS runtimes. Spec: https://fetch.spec.whatwg.org/#ref-for-dom-requestinit-duplex WHATWG discussion: whatwg/fetch#1254 Node discussion: nodejs/node#46221
Version
v18.13.0
Platform
Linux xxx 5.15.0-58-generic #64~20.04.1-Ubuntu SMP Fri Jan 6 16:42:31 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
undici
What steps will reproduce the bug?
Run the following line of code (in REPL or a script)
How often does it reproduce? Is there a required condition?
All the time.
What is the expected behavior?
No error thrown.
What do you see instead?
Additional information
Behavior of other versions:
v16.19.0
fails,v.16.18.1
works (with--experimental-fetch
option andReadableStream
imported fromstream/web
)>= 19.1
fails,19.0.1
worksv18.12.1
and lower worksThe text was updated successfully, but these errors were encountered: