Resumable Large-File Upload

Model response

For files under roughly 100MB on a reasonable connection, that is genuinely the right answer and the extra complexity here would be waste. The reasons it stops working are concrete rather than theoretical. Proxies and load balancers commonly enforce body-size limits and idle timeouts around sixty seconds, so a large single request gets killed by infrastructure the frontend does not control. More importantly, a single request is all-or-nothing: a dropped connection at 95% costs the entire transfer, and on mobile that is not a rare event, it is the normal case for a multi-gigabyte file. And there is no resume story at all, because the browser gives you no handle on what was already transmitted. So my rule is a size threshold: single request below it, chunked above it, behind the same component API so the caller does not care which path ran.

Model response

Both of those are real losses and I am trading them deliberately. Hashing four gigabytes means reading every byte before the first one is sent — a couple of minutes of CPU on a laptop, longer on a phone, during which the user sees a progress bar that has not moved. That is a bad enough experience that I would rather give up dedup by default. The integrity concern is partly covered elsewhere: object storage returns a per-chunk ETag, and the complete call verifies the assembled set, so corruption in transit is caught even without a client-side digest. Where I would reverse this is a product where dedup is a headline feature, like a backup client, and there the right implementation is incremental — hash chunk by chunk on a Worker as each chunk is uploaded, so hashing overlaps the transfer instead of preceding it, and ask the server after the first chunk whether it already has the file.

Model response

That is accurate, and for a product with strict content requirements it is a serious objection. What I would not accept is the implied alternative of proxying every byte through the API tier, because that turns a stateless API into a bandwidth-bound service, makes autoscaling a function of upload volume, and puts multi-minute connections through infrastructure sized for millisecond requests. The pattern I would use instead is a quarantine bucket: presigned uploads land in a staging location the application cannot read from, an object-created event triggers scanning and validation, and only then is the object promoted to its real home. The frontend consequence is that complete does not mean available — there is a processing state after upload — and I would model that in the UI rather than hide it. If the requirement were synchronous rejection before the bytes are stored at all, then proxying is the only option and I would size the tier for it.

Model response

You are right about the constraint and I should be precise about what resume does and does not buy. A File reference from an input element is not serializable, so after a browser restart the user must reselect the file; I cannot avoid that. What persistence buys is that reselecting costs one click instead of re-uploading three gigabytes, because the chunk manifest tells me the file was 80% done and the server confirms which parts it holds. Within a session the value is larger still, since a navigation, a crash of a single tab, or an offline period resumes with no user action at all. There is a path to true handle persistence — the File System Access API lets you store a FileSystemFileHandle in IndexedDB and re-acquire it after a permission prompt — but it is not available across all browsers, so I would treat it as an enhancement rather than the design. The honest framing is that this is resumable transfer, not resumable file access.