-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
fix(fetch): properly release fetch during long-lived stream handling #13967
base: develop
Are you sure you want to change the base?
Conversation
…tream is cancelled - Modified `resolveResponse` to properly handle the cancellation of child streams by overriding the `cancel` method on the parent response's body. - Updated unit tests to cover scenarios for both successful stream resolution and error cases involving stream cancellation.
I saw some errors in the CI. I'll deal with them later |
It seems that there are no further errors related to this PR. Can you please help confirm this, @chargome . |
Response was already in the code before, but now it's triggering a TS2304 error. Do you have any idea why this is happening? It looks like only the TS2304 error and the file size check remain to be solved now. |
@Lei-k not sure, but the same error is also crashing |
All tests have passed on my side. Please check, thanks! |
Hi, @chargome There’s one remaining bundle size check that failed due to the size limit. Could you assist me in adjusting the size, or do you have any suggestions for resolving this? |
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.
Hey @Lei-k sorry for the silence on this one, could you please have a look at my review and potentially also merge develop into your pr? We had some changes to our package structure lately, e.g. @sentry/types got deprecated.
if (res && res.body) { | ||
const body = res.body; | ||
const responseReader = body.getReader(); | ||
async function resloveReader(reader: WebReadableStreamDefaultReader, onFinishedResolving: () => void): Promise<void> { |
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.
async function resloveReader(reader: WebReadableStreamDefaultReader, onFinishedResolving: () => void): Promise<void> { | |
async function resolveReader(reader: WebReadableStreamDefaultReader, onFinishedResolving: () => void): Promise<void> { |
* | ||
* Export For Test Only | ||
*/ | ||
export function resolveResponse( |
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 think we might be introducing a potential memory leak within this function. Previously we were cancelling the resolving after a max timeout plus a timeout for individual chunk resolving. Could you explain why you removed these?
Hi,
I saw that the
trackFetchStreamPerformance
option was introduced in PR #13951 to bypass this issue, and Issue #13950 was closed as a result. However, this hasn't fully resolved the problem, so I attempted to address it in this PR.Here is my modified test result after applying the changes: