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
uppy/.changeset
History
Prakash 4652dc6a4a
upgrade aws-sdk in @uppy/companion (#6180) 
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.
2026-02-13 18:03:55 +05:30
..
bumpy-cougars-open.md @uppy/utils,@uppy/xhr-upload: create and use new queue (#6105) 2026-02-05 15:46:45 +01:00
config.json Update config.json (#5964) 2025-09-11 23:01:54 +02:00
good-chicken-brake.md @uppy/companion: fix 429 not returning JSON response with message (#6177) 2026-02-09 20:41:26 +08:00
README.md Migrate to changesets from custom release tooling (#5840) 2025-07-24 09:24:09 +02:00
rich-emus-arrive.md upgrade aws-sdk in @uppy/companion (#6180) 2026-02-13 18:03:55 +05:30

README.md

Changesets

Hello and welcome! This folder has been automatically generated by @changesets/cli, a build tool that works with multi-package repos, or single-package repos to help you version and publish your code. You can find the full documentation for it in our repository

We have a quick list of common questions to get you started engaging with this project in our documentation