1858705 - Fetch API does not return the entire response body when streaming a large response and performing CPU intensive processing in a Web Worker

Status: RESOLVED DUPLICATE of bug 1849860

(Core :: DOM: Workers, defect)

Description

[dominik.luntzer]

Attachment: stream.js

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

The attached example script uses a Web Worker to stream a large file with the fetch API and performs a CPU intensive task on each chunk.

To reproduce the issue it is crucial that processing is the bottleneck of the entire streaming-process (aka data is delivered faster over the network than it can be processed).

User Agent String: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0

Actual results:

Parts of the response can be retrieved by ReadableStreamDefaultReader.read() but after some time the returned promise is neither fulfilled nor rejected.

Network monitor shows a successful request

Expected results:

The entire response should be accessible via ReadableStreamDefaultReader.read().

That is the case if:

• the processing operation is removed or only takes a small amount of time
• network connection is throttled
• the same code is executed in the page directly instead of using a Web Worker

Other observations:

• WebWorker: chunk size always equals 64KB & network monitor already shows a complete request while the response is still being processed
• Without WebWorker: chunk size varies much more & network monitor shows an in-progress request while the response is being processed

Comment 1

[dominik.luntzer]

Attachment: index.html

Comment 2

[dominik.luntzer]

Attachment: index_without_webworker.html

Comment 3

[dominik.luntzer]

Attachment: screenshot.png

Comment 4

[Eden Chuang[:edenchuang]]

Kagami, is this the same as 1849860?

Comment 5

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: 1858705.html

(Attaching one-file version)

It seems yes.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

We'll track this in bug 1849860, thank you for reporting this!