ivandika3 commented on PR #9340: URL: https://github.com/apache/ozone/pull/9340#issuecomment-3570389129
@Gargi-jais11 Thanks for the reply. From the reply (https://github.com/minio/minio/discussions/13495#discussioncomment-1518062) > I want to confirm the behavior of `AbortMultipartUpload`, whether it is idempotent: > > * If `AbortMultipartUpload` is idempotent, then maybe it should not return `NoSuchUpload` even the multipart upload has been aborted. > * If `AbortMultipartUpload` is non-idempotent, maybe [the comments](https://github.com/minio/minio/blob/master/cmd/fs-v1-multipart.go#L801-L804) should be updated. I get the impression that returning 404 will means that it is idempotent. Afterwards, the discussion continued by saying that Minio returns NoSuchUpload (404) instead of 204 because it's consistent. The odd thing is that mint is made created by minio, so this suggests that minio is not s3-compatible? > AWS-SDK-PHP documentation [says](https://docs.aws.amazon.com/aws-sdk-php/v3/api/api-s3-2006-03-01.html#abortmultipartupload:~:text=If%20present%2C%20this,No%20Content) For Ozone to be compatible with AWS SDKs, it must adhere to this idempotency. The original test failed because the aws-sdk-php received a 404 and threw a client exception, proving it expects a non-error code (204) in this scenario. The doc you attached seems to be about [x-amz-if-match-initiated-time](https://docs.aws.amazon.com/AmazonS3/latest/API/API_AbortMultipartUpload.html#API_AbortMultipartUpload_RequestSyntax) for directory bucket. My understanding about "idempotency" is that abort multipart upload is always idempotent since there is no side effect on sending duplicate abort multipart upload request (only one multipart upload will be aborted). I think for 204 vs 404, we might need to check these two cases: - Abort multipart upload that was initiated before (i.e. it exists before): This might return 204 to show that there is a successful abort multipart upload before - Abort multipart upload that was never initiated (i.e. it does not exist): This might return 404 NoSuchUpload since there was no successful abort itself. If there is a distinction between the two, then we might need a separate way to check which multipart upload ID was aborted recently. I think the best way for us to check is to simply create a real AWS S3 account and verify the behavior. Since the official AWS S3 documentation only mentions 404 for no multipart uploads, changing to 204 might not be the right way to go. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
