Gargi-jais11 commented on PR #9340:
URL: https://github.com/apache/ozone/pull/9340#issuecomment-3698406320

   Thanks @ivandika3 for the testing and analysis. Ahh I see now the picture is 
clear to us as follows:
   **AWS S3 behavior:**
   
   - Abort an upload that existed → 204
   - Abort the same upload again → 204 (idempotent)
   - Abort an upload that never existed → 404
   
   **Current Ozone implementation:**
   
   - After abort, entries are deleted from openKeyTable and multipartInfoTable
   - A subsequent abort finds no metadata and throws 
NO_SUCH_MULTIPART_UPLOAD_ERROR
   - We can’t distinguish `was aborted` vs `never existed` because the metadata 
is gone.
   
   The current code correctly returns **404** for uploads that never existed. 
To match **AWS’s idempotent 204**, we’d need to track aborted uploads, which 
adds unnecessary complexity. 
   **To match AWS exactly, we would need to roighly follow below steps:**
   
   - Track aborted uploads (e.g., a new table or flag in existing metadata)
   - Check this record when NO_SUCH_MULTIPART_UPLOAD_ERROR is thrown
   - Return 204 if previously aborted, 404 if never existed
   - Implement cleanup/expiration for this tracking data
   
   >  I asked Claude on Cursor about this and the result is as follows
   
   
[cursor_s3_abort_multipart_upload_http_s.md](https://github.com/user-attachments/files/24271694/cursor_s3_abort_multipart_upload_http_s.md)
   
   Since the grace period is not known to us that after how much it will throw 
404 error, we can't fix the expiration time of previously aborted uploads and 
defining this expiry by our own could again cause inconsistency.
   
    I too prefer keeping the current behaviour unless AWS compatibility is 
required. This is because ozone implementation of abort multipart uploads 
removes entires from **openKeyTable and multipartInfoTable** means no metadata 
so we can keep 404 error.


-- 
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]

Reply via email to