fix(fetch): properly release fetch during long-lived stream handling #13967
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.
Lei-k
changed the title
|
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? |
| 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.
| 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.
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?
There was a problem hiding this comment.
@Lei-k could you address this concern?
Hi,
I saw that the
trackFetchStreamPerformanceoption 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: