fix: fix the linux patch#2703
Conversation
65ff9e1 to
cf4d90d
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2703 +/- ##
==========================================
- Coverage 85.54% 85.28% -0.27%
==========================================
Files 76 84 +8
Lines 6858 7584 +726
==========================================
+ Hits 5867 6468 +601
- Misses 991 1116 +125 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
6bfdfc2 to
6220fe3
Compare
6220fe3 to
a5c9a2e
Compare
| const pullAlgorithm = async () => { | ||
| await fetchParams.controller.resume() |
There was a problem hiding this comment.
While debugging I realized that we call pullAlgorithm with an await but as pullAlgorithm is not an async function it basically "decouples" the promise logic and the await is pointless.
Line 1941 in cf4d90d
So with this change the await pullAlgorithm will actually have something to await.
| // 9. If stream doesn’t need more data ask the user agent to suspend | ||
| // the ongoing fetch. | ||
| if (!fetchParams.controller.controller.desiredSize) { | ||
| if (fetchParams.controller.controller.desiredSize <= 0) { |
There was a problem hiding this comment.
According to MDN desiredSize can go negative if the stream is oversaturized. !(-1) is false. And if desiredSize is 0, then we know we can not push data, anyway. 0 would actually mean, that the stream is closed. So is my change correct?
https://developer.mozilla.org/en-US/docs/Web/API/ReadableByteStreamController/desiredSize
So when the stream was closed we tried to read again from it.Well... at this point i dont know...I guess the problem was, that the readable stream can get suspended. So when the readable stream is unsuspended, and pull gets called a second time, than we try to get again a reader. But you can have only one reader on the stream, thus it breaks. Now it gets the reader only once.