Repository navigation
Keep the service worker alive during direct downloads - #45
Merged
Merged
Conversation
Firefox stops a service worker after 30 s without events, and messages on the MessageChannel carrying the file don't count as activity. The worker streaming a direct (WebRTC) download was killed mid-transfer, cutting big files short around 400 MB at LAN speed while the page still reported the session as done. The page now pings the worker every 10 s while a download runs, and for a minute after it ends so the worker can flush to disk. Existing workers already ignore the new message, so the fix works before they update. Verified with a throttled 1 GB transfer: Firefox was cut at exactly the worker idle timeout before, and completes byte-identical in 21 min after. Chrome and the relay were not affected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Large files transferred directly (WebRTC) to a Firefox receiver stopped around 400 MB.
The service worker that streams a direct transfer into the browser download is stopped by Firefox after 30 s without events. Chunks arrive on a
MessageChannelport, which doesn't count as activity, so the worker is killed mid-transfer and the download is cut short. At LAN speed (~13 MB/s), 30 s is about 400 MB. The page still finishes receiving, so the server logsclosed: doneand the truncation never showed up in the logs.Fix
rtc.js: while a direct download runs, and for 60 s after it ends so the worker can flush to disk, the page sends{type: 'keepalive'}to the service worker every 10 s. The pings stop on cancel or abort.sw.js: comment only. Existing workers already ignore the message, and receiving it is enough to keep them alive, so the fix works before they update.index.html: bumprtc.js?v=4.Verification
1 GB transfers in real browsers (Playwright), with the sender throttled to real-world speeds:
bundle exec rspec: 57 examples, 0 failures.