Skip to content

Commit bd5fbb8

Browse files
committed
Improve comments
1 parent 58930ae commit bd5fbb8

2 files changed

Lines changed: 4 additions & 8 deletions

File tree

services-custom/s3-transfer-manager/src/test/java/software/amazon/awssdk/transfer/s3/internal/S3JavaMultipartTransferProgressListenerTest.java

Lines changed: 1 addition & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -367,9 +367,6 @@ void copyWithJavaBasedClient_listeners_reports_ProgressWhenSuccess_copy() {
367367
/**
368368
* Verifies that TransferListener callbacks fire for unknown-content-length uploads that fit in a single chunk.
369369
* This is the scenario where UploadWithUnknownContentLengthHelper routes to uploadInOneChunk.
370-
* Before the fix, only transferInitiated fired; transferComplete never fired because endOfStreamFuture
371-
* was never completed (the wrapper body was bypassed by splitCloseable and uploadInOneChunk did not
372-
* signal the progress listener).
373370
*/
374371
@Test
375372
void unknownContentLength_singleChunk_transferCompleteFires() {
@@ -410,8 +407,7 @@ void unknownContentLength_singleChunk_transferCompleteFires() {
410407

411408
/**
412409
* Verifies that TransferListener callbacks fire for unknown-content-length uploads that exceed the part size
413-
* and go through the multipart upload path. This path was already working before the fix because
414-
* multipartClientProgressListener compensates for the wrapper body being bypassed by splitCloseable.
410+
* and go through the multipart upload path.
415411
*/
416412
@Test
417413
void unknownContentLength_multiChunk_allCallbacksFire() {

services/s3/src/main/java/software/amazon/awssdk/services/s3/internal/multipart/MultipartUploadHelper.java

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -173,9 +173,9 @@ void uploadInOneChunk(PutObjectRequest putObjectRequest,
173173
asyncRequestBody.contentLength().ifPresent(progressListener::subscriberOnNext);
174174
}
175175
// Always signal completion so that TransferProgressUpdater's endOfStreamFuture completes
176-
// and the TransferListener's transferComplete callback fires. This is critical for the
177-
// unknown-content-length single-chunk path where splitCloseable() bypasses the wrapper body
178-
// that would normally complete endOfStreamFuture via subscriberOnComplete.
176+
// and the TransferListener's transferComplete callback fires.
177+
// For unknown content length we don't know if it wil lbe one chunk or not ahead of time
178+
// and so don't set REPORT_PROGRESS_IN_SINGLE_CHUNK attribute.
179179
progressListener.subscriberOnComplete();
180180
returnFuture.complete(response);
181181
});

0 commit comments

Comments
 (0)