Hello !
I’m using Uppy with @uppy/aws-s3 and multipart uploads in a React (Next.js) application. I wanted to sanity-check some progress behavior I’m seeing before opening a GitHub issue.
Scenario
-
File size > ~5MB (multipart upload)
-
Upload starts and reaches ~50% (example)
-
Upload is paused
-
On resume, Uppy calls ListParts to fetch already uploaded parts from S3
-
Based on the response, Uppy recalculates progress and finds that only ~40% of parts were fully uploaded
-
The progress then jumps back from ~50% → ~40% and continues uploading
The upload itself works correctly — this is purely about progress reporting / UX
My understanding
From what I can tell, this behaviour is Uppy reconciling optimistic client-side progress with S3’s authoritative ListParts response during multipart resume.
From a correctness standpoint, this makes sense - only fully uploaded parts should count toward progress.
However, visually this appears as a flicker or regression in the progress bar, which can be confusing or concerning for users, especially when pause/resume is user-initiated.
Hello , You’re correct , The upload chunk is rebuilt using only confirmed parts, so
those partial bytes vanish from the total, causing the progress drop upon resuming.
But this is fundamentally correct behavior displaying a higher number would be misleading since those bytes genuinely need re-upload.
Hello!
Yes, I understand, but the visual regression of the progress bar seems inappropriate.
Would it make sense to keep the UI progress at the last displayed value until the re-uploaded chunks naturally catch up, and then continue progressing from there?
Internally the upload would still reconcile with the ListParts response, but the progress indicator would not visibly move backwards.
Hey, any help would be greatly appreciated !
hello we discussed your suggestion internally with the uppy team i.e. to hold the bar at its last value until the re-upload catches up , I think it comes with it’s own sets of quicks because the held value would be a lie for the duration of the re-upload, time-remaining/speed estimates would be wrong, and it complicates genuine cases where progress should move (e.g. a failed part actually needing redo). Today the bar shows the “factually accurate” state since there’s no way to resume a partially-uploaded part in S3.
The cleaner long-term approach would be to not count a part toward progress until it’s confirmed complete (progress by confirmed parts rather than streamed bytes), which avoids this issue in the first place. That said, it’ll be a substantial change, and with a lot many things already on our plate right now, it’s not something we can prioritize right now. Thanks for your suggestion on this !