Gargi-jais11 commented on PR #9340: URL: https://github.com/apache/ozone/pull/9340#issuecomment-3568984471
I believe that the behavior of `204 No Content` for an already-aborted upload is not legacy behavior tied to eventual consistency. The goal of `AbortMultipartUpload` is to ensure the upload is gone. If it's already gone, the goal is achieved successfully. To maintain a consistent client experience, the API must not raise an error. 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 question is why does the mint test expect 204 no content? If Minio also requires returning 404, then it might be the Mint test bug? The Mint test expects 204 No Content because it is validating compliance with the idempotency of the AWS S3 API, which all AWS SDKs are built to follow. -- 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]
