allthingssecurity opened a new pull request, #28427: URL: https://github.com/apache/camel/pull/28427
# Description [CAMEL-25903](https://issues.apache.org/jira/browse/CAMEL-25903) With `multiPartUpload=true`, the S3 producer uploads a body that is at least `partSize` long with `CreateMultipartUpload` / `UploadPart` / `CompleteMultipartUpload`, and a smaller one with a single `PutObject`. It computed the user metadata from the `CamelAwsS3Metadata` header on both paths, but only the single put sent it: the `CreateMultipartUploadRequest` never got it, so an object uploaded in parts was stored without user metadata, with no error and nothing logged. The S3 consumer sets `CamelAwsS3Metadata` to the metadata of the object it read, so a route that copies objects between buckets with multipart upload kept the metadata of the small objects and dropped it for the large ones. Changes: - `AWS2S3Producer.processMultiPart` sets the metadata on the `CreateMultipartUploadRequest`. - The `Content-Length` entry that the multipart path added to the metadata map (never sent) is removed, so it does not turn into an `x-amz-meta-content-length` entry now that the map is sent. No option, documentation or upgrade-guide change: objects now get the metadata the route asked for, and there is nothing for users to do. Tests: - New `AWS2S3ProducerMultipartMetadataTest` (2 tests, Mockito `S3Client` as in the other producer tests of the module, `partSize=5`). `multipartUploadStoresTheUserMetadata` (12 byte body, 3 parts) fails on main with `expected: {"checksum"="abc123", "origin"="camel"} but was: {}`. `bodySmallerThanThePartSizeStoresTheUserMetadata` is a control: the single put keeps the metadata on main and with the fix. - camel-aws2-s3 unit tests: 118 run, 0 failures, 0 errors, 0 skipped. They were run with the AWS SDK 2.55.15 jars of my local repository (`-Daws-java-sdk2-version=2.55.15`, main is on 2.56.0); the request builders used here are the same in both. What was not run: the ITs (they need Docker / AWS); the full root build. Not changed: with `useCustomerKey=true` (SSE-C) the `UploadPartRequest`s of the multipart path do not carry the customer key, which S3 requires for each part, so such uploads fail (loudly). The streaming upload producer (`AWS2S3StreamUploadProducer`) does not send user metadata at all; it writes several exchanges into one object, so which exchange's metadata to use is a design question. I can file follow-up JIRAs for both. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25903](https://issues.apache.org/jira/browse/CAMEL-25903). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-aws2-s3, including the formatter and import-sort plugins; no generated file changes. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
