Open supersoniko opened 4 weeks ago
Latest commit: 1dd79c8ffd921ab677b36da0b7c448768af53a22
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
Yeah I see hacks on hacks in there. I'm glad you figured something out. That being said. I'm going to probably need to test this fix against Vercel/Netlify edge as I thought the creation of the new Request was to get around stream locking so this fix may impact them.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
https://github.com/solidjs/solid-start/blob/main/packages/start/src/runtime/server-handler.ts#L136 There's currently a workaround for edge runtimes to create a new Request object instead of using the current one.
What is the new behavior?
Add a safeguard for the edge runtime workaround when a stream is already locked to not create the new Request object.
Other information
My goal is to make Solid Start work 100% on the Azure Functions runtime. I currently have a PR open at Nitro to support the latest Azure Function runtime.
However there's currently an issue that the H3 event body stream is already locked when it gets to the part of the edge runtime workaround when running on Azure Functions, which causes issues with server actions.
Im happy to say that all Solid Start functionality seems to work on Azure Functions once we get around this locking issue.