davsclaus opened a new pull request, #24859:
URL: https://github.com/apache/camel/pull/24859
## Summary
Fixes three bugs in `AWS2S3StreamUploadProducer` that cause data loss and
orphaned multipart uploads when `multiPartUpload=true` and the body is larger
than `partSize`:
- **`maxRead` not reset after batch-flush**: after a batch completion,
`maxRead` stayed at 0, so `toByteArray(is, 0)` read nothing and the loop exited
with remaining data unread. Added `maxRead = partSize` reset (guarded by
`isMultiPartUpload()`) in both `processWithoutTimestampGrouping` and
`processWithTimestampGrouping`.
- **`createMultipartUpload` called on every iteration**: CAMEL-20728 changed
`state.index++` to `state.index = 1`, breaking the `if (state.index == 1)`
guard so `createMultipartUpload` fired on every loop iteration. Each call
returned a new `uploadId`, orphaning parts from earlier iterations and accruing
storage charges. Changed guard to `if (state.initResponse == null)`.
- **`maxRead` going negative**: when `uploadAggregate.buffer.size() >
partSize`, subtracting it from `maxRead` drove `maxRead` negative, silently
dropping the next exchange body. Added `Math.max(1, maxRead)` clamp.
## Test plan
- [x] Added `AWS2S3StreamUploadMultipartTest` with 3 unit tests (mocked
S3Client):
- Body larger than `partSize` is not truncated
- `createMultipartUpload` called exactly once per upload
- Multiple parts use sequential part numbers and the same upload ID
- [x] All existing unit tests pass (18/18)
- [x] All existing integration tests pass (including
`S3StreamUploadMultipartIT` and `S3StreamUploadMultipartAsyncIT`)
_Claude Code on behalf of davsclaus_
Co-Authored-By: Claude Opus 4.6 <[email protected]>
--
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]
