Persist FSA partial downloads more frequently #182

New issue

Open

opened 2026-08-28 13:59:53 +00:00 by aaperis · 0 comments

aaperis commented

2026-08-28 13:59:53 +00:00

(Migrated from github.com)

Please describe the feature

As a user on an unreliable connection (e.g. bad wifi), I want partial download progress to be flushed to disk frequently, so that a dropped connection loses seconds of transfer rather than potentially hundreds of MB.

Detailed description

In the current implementation of #149, folder downloads are persisted to disk every 512 MB. On slow or unstable links a connection can die before the first flush, forcing the whole chunk to be re-fetched on resume.

The File System API supports a native flushing mechanism that avoids the inherited open/close bottlenecks of the crswap used by FSA API. However flush() is only available for OPFS. So, this issue implies a migration to OPFS workers for the download.

AC

Flush on a time-based interval in addition to the size threshold (e.g. every N seconds).
Test and choose optimal time and size intervals (if size intervals become redundant, drop them altogether)
Make sure download and resume functionality works as before.
Have the time interval as a named constant that is easy to tune.

Notes

Follow-up to #173 .
Mentioned in #193 which includes a detailed description as to why the current implementation creates bottlenecks.

## Please describe the feature As a user on an unreliable connection (e.g. bad wifi), I want partial download progress to be flushed to disk frequently, so that a dropped connection loses seconds of transfer rather than potentially hundreds of MB. ## Detailed description In the current implementation of #149, folder downloads are persisted to disk every 512 MB. On slow or unstable links a connection can die before the first flush, forcing the whole chunk to be re-fetched on resume. The File System API supports a native [flushing mechanism](https://developer.mozilla.org/en-US/docs/Web/API/FileSystemSyncAccessHandle/flush) that avoids the inherited open/close bottlenecks of the crswap used by FSA API. However `flush()` is only available for [OPFS](https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system). So, this issue implies a migration to OPFS workers for the download. ## AC - [ ] Flush on a time-based interval in addition to the size threshold (e.g. every N seconds). - [ ] Test and choose optimal time and size intervals (if size intervals become redundant, drop them altogether) - [ ] Make sure download and resume functionality works as before. - [ ] Have the time interval as a named constant that is easy to tune. ## Notes Follow-up to #173 . Mentioned in #193 which includes a detailed description as to why the current implementation creates bottlenecks.