[BUG] AsyncTransferManager eatingup exception

[dhwanilpatel]

Describe the bug
In AsyncTransferManager, at one place we are only throwing the exception. Considering it will be run in different thread, this exception might be lost from invoking thread, we should invoke returnFuture.completeExceptionally from there, so invoking thread's action listener will be invoked and appropriate action would be taken.

OpenSearch/plugins/repository-s3/src/main/java/org/opensearch/repositories/s3/async/AsyncTransferManager.java

Lines 352 to 361 in 5bd413c

	returnFuture.completeExceptionally(throwable);
	} else {
	try {
	uploadRequest.getUploadFinalizer().accept(true);
	} catch (IOException e) {
	throw new RuntimeException(e);
	}
	returnFuture.complete(null);
	}

[shwetathareja]

@vikasvb90 to take a look.

[vikasvb90]

@dhwanilpatel I don't see the exception getting masked. I tested exceptions both from corrupted as well as IO block and I can see them propagated to S3BlobContainer here which is invoking onFailure of the completionListener. In fact, I can also see abort operation like deleteObject in single chunk upload getting invoked.

Can you mention a scenario where you saw this getting masked?

[vikasvb90]

Also, it will be incorrect to invoke returnFuture from that block or any part failure block because if we do that then we will never be able to clean up uploaded data which is happening in the subsequent chained handle blocks which is dependent on the exception to trigger cleanup.

[Bukhtawar]

We decided to close it for now and pick it up with the broader Virtual Thread migration effort.

[Storage Triage - attendees 1 2 3 4 5 6 7 8 9] 10