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
fix: properly stream uploadData
in protocol.handle()
#41052
fix: properly stream uploadData
in protocol.handle()
#41052
Conversation
💖 Thanks for opening this pull request! 💖 We use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix. Examples of commit messages with semantic prefixes:
Things that will help get your PR across the finish line:
We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can. |
hey @BurningEnlightenment - thanks for this! We'll try to get to reviewing it soon - |
No pressure, I'm applying these fixes currently via monkey patching Some additional thoughts:
|
@codebytere and @nornagon know the context better than me but it looks like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, these are good changes (and good tests!)
Regarding the unused statusText
property, good catch, that should probably be plumbed through to the underlying HttpResponseHeaders—currently we use net::GetHttpReasonPhrase
to derive the status text from the status code instead.
// Note that even though `getBlobData()` is a `Session` API, it doesn't | ||
// actually use the `Session` context. Its implementation solely relies | ||
// on global variables which allows us to implement this feature without | ||
// knowledge of the `Session` associated with the current request by | ||
// always pulling `Blob` data out of the default `Session`. | ||
controller.enqueue(await session.defaultSession.getBlobData(chunk.blobUUID)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this should be fixed to not be an instance method then 😅 but won't block on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you. I just wanted to sidestep a potential API design review process (and it would've bumped this from semver/patch to at least a semver/minor change).
Btw. if the getBlobData()
API gets touched it might also be prudent to rename blobUUID
to just blobId
as the implementation hasn't used UUIDs for quite some time. Should I submit a follow up PR potentially including some further changes outlined in my previous comments?
51031a5
to
50817e2
Compare
@BurningEnlightenment would you mind rebasing this to fix CI? there was an issue with WOA CI that's since been addressed. Beyond that:
Yes, I think your best course of action is to open a follow-up! The scope of this PR is good to merge for now and i'd rather address the issues herein first. |
Increase readability by moving the file stream creation logic out of the `uploadData` to request body conversion function.
50817e2
to
885ae8c
Compare
@codebytere done. LGTM |
Congrats on merging your first pull request! 🎉🎉🎉 |
Release Notes Persisted
|
I have automatically backported this PR to "28-x-y", please check out #41358 |
I have automatically backported this PR to "29-x-y", please check out #41359 |
This was primarily for getting the latest Electron, but I ran `yarn upgrade-interactive` and upgraded the other non-breaking deps (mostly dev) too. Reason for wanting electron is to try and see if this backport fixes the issue with our streams not getting faithfully written: electron/electron#41052 In some ad-hoc and quick testing, I noticed that the new `writeStream` we've implemented works fine for files up to 128 K, presumably some chunk size, but then begins to diverge. Sounds similar (but not exactly the same) as this issue: electron/electron#39658 Unfortunately, this didn't fix the issue we're facing, so our case is perhaps different.
Description of Change
Fixes a few annoying bugs which prevented requests intercepted with
protocol.handle()
from being properly forwarded tonet.fetch()
:Fixes #39658
Fixes #40754
Fixes #40826
I considered submitting multiple pull requests, but the fixes would've generated conflicts with each other. In essence I've just streamlined the
pull()
implementation ofconvertToRequestBody()
and added a test case for every fixed bug. I also added an explicit error condition in case an unknown/new chunk type gets pushed into the protocol handler. Otherwise it is veryunobvious and hard to figure out why your request has been mutilated.
If you like, I am willing to fix the chunk type definitions / remove the
any
casts. However, I'd need some guidance on whether I should introduce localtype
s or add them to the public API.Additionally I noticed while reviewing the C++ parts that the
cb
, which is passed to the actual handler functionasync (preq: ProtocolRequest, cb: any)
, never accesses thestatusText
property. Is there a reason for passingstatusText
in anyways?cc: @nornagon, @codebytere
Checklist
npm test
passesRelease Notes
Notes: Fix various bugs which could prevent forwarding requests intercepted with protocol.handle().