Abort every in-flight chunk when a chunked upload is canceled - #2371
Open
enyo wants to merge 1 commit into
Open
Conversation
`cancelUpload` aborted `file.xhr`, which only ever holds the request that started last. With `parallelChunkUploads` the other chunks kept streaming to the server for a file the UI already showed as canceled, and if the last chunk had finished, `file.xhr` pointed at a completed request and the abort did nothing at all. Each chunk already carries its own `xhr`, so walk `file.upload.chunks` and abort the ones still uploading. Non-chunked uploads keep aborting `file.xhr` as before. Fixes #2366 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Coverage Report
File Coverage
|
||||||||||||||||||||||||||||||||||||||
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.
Fixes #2366.
The bug
_uploadDatastores its request on the file:With
parallelChunkUploadsthat runs once per concurrent chunk, sofile.xhrends up holding whichever request started last.cancelUploadaborts only that one:Cancel a 3-way parallel chunked upload and two of the three requests keep streaming to the server. They are silent about it:
files[0].statusis alreadyCANCELED, so_finishedUploadingand_handleUploadErrorboth return early and nothing is emitted. The user's bandwidth keeps going, and the server keeps receiving chunks for a file the UI says was canceled. Worse, if that last chunk had already completed,file.xhrpoints at a finished request andabort()does nothing at all while the others are still live.The fix
Each chunk already carries its own
xhr(file.upload.chunks[i].xhr, set in_uploadDataand cleared on success), socancelUploadwalks the chunks and aborts the ones stillUPLOADING, marking themCANCELED. Non-chunked uploads keep abortingfile.xhrexactly as before.Test
should abort every chunk still in flight when the upload is canceledstarts a 6-chunk upload withparallelChunkUploads: 3and cancels it. Againstmainthe assertion readsexpected [ false, false, true ] to deeply equal [ true, true, true ]— the reported behaviour, exactly.One thing I noticed but did not touch
cancelUploadopens withthis._getFilesWithXhr(file.xhr!). When a file is canceled during the_transformFileswindow it is alreadyUPLOADINGbut has noxhryet, so that call matches every file whosexhris stillundefined— i.e. every queued file — and marks them allCANCELEDwith acanceledevent each. That is a separate bug from the one reported here, so I left it alone; happy to do it in its own PR.