Mirrors/uppy
1
0
Fork 0
mirror of https://github.com/transloadit/uppy.git synced 2026-07-17 16:50:22 +00:00
Code Issues Projects Releases Wiki Activity

upgrade aws-sdk in @uppy/companion (#6180)

Browse source 
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.
This commit is contained in:
Prakash 2026-02-13 18:03:55 +05:30 • committed by GitHub
parent f6efd2ebcc
commit 4652dc6a4a
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 1198 additions and 256 deletions
Download patch file Download diff file Expand all files Collapse all files

5
.changeset/rich-emus-arrive.md Normal file
View file

@ -0,0 +1,5 @@
---
"@uppy/companion": patch
---
upgrade @aws-sdk/ deps in @uppy/companion

10
packages/@uppy/companion/package.json
View file

@ -34,11 +34,11 @@
],
"bin": "./bin/companion",
"dependencies": {
"@aws-sdk/client-s3": "^3.338.0",
"@aws-sdk/client-sts": "^3.338.0",
"@aws-sdk/lib-storage": "^3.338.0",
"@aws-sdk/s3-presigned-post": "^3.338.0",
"@aws-sdk/s3-request-presigner": "^3.338.0",
"@aws-sdk/client-s3": "3.986.0",
"@aws-sdk/client-sts": "3.986.0",
"@aws-sdk/lib-storage": "3.986.0",
"@aws-sdk/s3-presigned-post": "3.986.0",
"@aws-sdk/s3-request-presigner": "3.986.0",
"body-parser": "1.20.4",
"common-tags": "1.8.2",
"connect-redis": "7.1.1",

1439
yarn.lock
View file

File diff suppressed because it is too large Load diff