mirror of
https://github.com/transloadit/uppy.git
synced 2026-07-17 16:50:22 +00:00
4652dc6a4a
this fixes #6167
AI summary :
**The Bug: S3 Multipart Upload Fails with InvalidPart**
**What happened**
When uploading large files (200MB+) from Google Drive → Companion → S3
using multipart upload, the upload would reach ~96-100% and then fail
with S3's `InvalidPart` error on `CompleteMultipartUpload`.
*Root cause*
_A version mismatch between two AWS SDK packages caused by yarn dedupe._
Commit `3c3034b40` ("Dedupe dependencies #6085") ran `yarn dedupe`.
Companion had `@aws-sdk/client-s3` and `@aws-sdk/lib-storage` both at
`"^3.338.0"`, which previously both resolved to `3.600.0`. But the
`@uppy/transloadit` package elsewhere in the monorepo had
`"@aws-sdk/client-s3": "^3.891.0"`. Dedupe merged the resolutions —
`client-s3` jumped to `3.896.0` while `lib-storage` stayed at `3.600.0`.
*Why the mismatch matters*
AWS SDK `client-s3@3.896.0` introduced a _breaking behavioral change_ in
its checksum middleware:
• *Old (3.600.0):* Default checksum = MD5, no auto-injection.
`UploadPart` requests sent _no checksum header_.
• *New (3.896.0):* Default checksum = CRC32,
`requestChecksumCalculation` defaults to `"WHEN_SUPPORTED"`. The
middleware _auto-injects `x-amz-checksum-crc32`_ on every `UploadPart`
request.
The old `lib-storage@3.600.0` didn't know about this new behavior. It
called `CreateMultipartUpload` _without_ setting `ChecksumAlgorithm`.
Then `client-s3@3.896.0` added CRC32 checksums to each `UploadPart`. S3
saw parts with checksums that weren't declared at creation time →
rejected with `InvalidPart` at `CompleteMultipartUpload`.
*How the fixes work*
_Option A — `requestChecksumCalculation: 'WHEN_REQUIRED'`_ (workaround):
Tells the new `client-s3` to only add checksums when S3 requires them
(which it doesn't for `UploadPart`). This restores the old behavior — no
checksum headers, no mismatch.
_Option B — Upgrade all AWS SDK packages to `^3.986.0`_ (proper fix):
The new `lib-storage@3.986.0` is _aware_ of the CRC32 checksum behavior.
When it detects `requestChecksumCalculation = "WHEN_SUPPORTED"`, it
explicitly sets `ChecksumAlgorithm: "CRC32"` on the
`CreateMultipartUpload` call. Now S3 expects CRC32 checksums on the
parts, the parts have CRC32 checksums → everything is consistent →
upload succeeds.
*TL;DR*
`yarn dedupe` upgraded `client-s3` but not `lib-storage`. The new
`client-s3` started adding CRC32 checksums to parts, but the old
`lib-storage` didn't declare CRC32 at multipart creation time. S3
rejected the mismatch. Fix: upgrade both packages together so they agree
on checksum behavior.
76 B
76 B
| @uppy/companion |
|---|
| patch |
upgrade @aws-sdk/ deps in @uppy/companion