# Multipart upload progress jumps backward on resume (AwsS3) **URL:** \ **Category:** Uppy\ **Created:** [January 17, 2026, 9:59am UTC](https://community.transloadit.com/t/multipart-upload-progress-jumps-backward-on-resume-awss3/17736 "2026-01-17T09:59:37Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![vidjanainesh](https://yyz2.discourse-cdn.com/flex032/user_avatar/community.transloadit.com/vidjanainesh/32/1429_2.png) [@vidjanainesh](https://community.transloadit.com/u/vidjanainesh)\ **Post date:** [January 17, 2026, 9:59am UTC](https://community.transloadit.com/t/multipart-upload-progress-jumps-backward-on-resume-awss3/17736/1 "2026-01-17T09:59:37Z")
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. ---
**Author:** ![qxprakash](https://yyz2.discourse-cdn.com/flex032/user_avatar/community.transloadit.com/qxprakash/32/1388_2.png) [@qxprakash](https://community.transloadit.com/u/qxprakash)\ **Post date:** [March 16, 2026, 12:20pm UTC](https://community.transloadit.com/t/multipart-upload-progress-jumps-backward-on-resume-awss3/17736/2 "2026-03-16T12:20:15Z")
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. ---
**Author:** ![vidjanainesh](https://yyz2.discourse-cdn.com/flex032/user_avatar/community.transloadit.com/vidjanainesh/32/1429_2.png) [@vidjanainesh](https://community.transloadit.com/u/vidjanainesh)\ **Post date:** [March 16, 2026, 12:41pm UTC](https://community.transloadit.com/t/multipart-upload-progress-jumps-backward-on-resume-awss3/17736/3 "2026-03-16T12:41:05Z")
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. ---
**Author:** ![vidjanainesh](https://yyz2.discourse-cdn.com/flex032/user_avatar/community.transloadit.com/vidjanainesh/32/1429_2.png) [@vidjanainesh](https://community.transloadit.com/u/vidjanainesh)\ **Post date:** [June 11, 2026, 12:38pm UTC](https://community.transloadit.com/t/multipart-upload-progress-jumps-backward-on-resume-awss3/17736/4 "2026-06-11T12:38:42Z")
Hey, any help would be greatly appreciated ! ---
**Author:** ![qxprakash](https://yyz2.discourse-cdn.com/flex032/user_avatar/community.transloadit.com/qxprakash/32/1388_2.png) [@qxprakash](https://community.transloadit.com/u/qxprakash)\ **Post date:** [June 17, 2026, 7:32pm UTC](https://community.transloadit.com/t/multipart-upload-progress-jumps-backward-on-resume-awss3/17736/5 "2026-06-17T19:32:21Z")
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. ---
**Author:** ![qxprakash](https://yyz2.discourse-cdn.com/flex032/user_avatar/community.transloadit.com/qxprakash/32/1388_2.png) [@qxprakash](https://community.transloadit.com/u/qxprakash)\ **Post date:** [June 17, 2026, 7:33pm UTC](https://community.transloadit.com/t/multipart-upload-progress-jumps-backward-on-resume-awss3/17736/6 "2026-06-17T19:33:49Z")
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 ! ---
**Author:** ![vidjanainesh](https://yyz2.discourse-cdn.com/flex032/user_avatar/community.transloadit.com/vidjanainesh/32/1429_2.png) [@vidjanainesh](https://community.transloadit.com/u/vidjanainesh)\ **Post date:** [June 23, 2026, 4:57am UTC](https://community.transloadit.com/t/multipart-upload-progress-jumps-backward-on-resume-awss3/17736/7 "2026-06-23T04:57:58Z")
Hello, I understand, thank you for your assistance !