)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":39146,"name":"Nathaniel Martes","display_name":"Nate Martes","email":"nmartes@NVIDIA.com","username":"nmartes"},"change_message_id":"e3557904da9b266460ff565194beb1865cf783a8","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"72caffe2_7fed23d9","updated":"2026-08-13 02:18:22.000000000","message":"The gist is, we block until `slo` starts sending us stuff only for checksum MPUs.\n\nI THINK this works...\nwe may be able to prevent this blocking in some cases if we actually do even more checking before we get to the hook.\n\nLike I think we can do a very earlier check on the hasher to make sure it exists for what we have written on the MPU. \n\nBut doing the validation for the request part vs the stored manifest and the final checksum calculation, not sure how else we can send something BEFORE we know those will be correct unless we wait for the hook to return","commit_id":"1b2c0c1c9aad133c6e8af416f00b7015d1023985"},{"author":{"_account_id":39146,"name":"Nathaniel Martes","display_name":"Nate Martes","email":"nmartes@NVIDIA.com","username":"nmartes"},"change_message_id":"8fe4b658d2a3df583554aa6c19e927dce62d9516","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"5fd215b0_13af6de8","in_reply_to":"72caffe2_7fed23d9","updated":"2026-08-13 02:21:11.000000000","message":"Another thing we can do is not block if we have no request meta to validate, like if the client did not give us `x-amz-checksum-*` or any request meta to validate for that matter and we know we have the proper hasher to calculate the final checksum, then we don\u0027t have to block I think","commit_id":"1b2c0c1c9aad133c6e8af416f00b7015d1023985"}],"swift/common/middleware/s3api/controllers/multi_upload.py":[{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"dc7e7501d23bd1c6be59cba44d81833067723c77","unresolved":true,"context_lines":[{"line_number":1493,"context_line":"                                    # keep delaying until we get SOMETHING"},{"line_number":1494,"context_line":"                                    # if we need to"},{"line_number":1495,"context_line":"                                    heartbeat_due \u003d True"},{"line_number":1496,"context_line":"                                    continue"},{"line_number":1497,"context_line":"                                if not yielded_anything:"},{"line_number":1498,"context_line":"                                    yield (b\u0027\u003c?xml version\u003d\"1.0\" \u0027"},{"line_number":1499,"context_line":"                                           b\u0027encoding\u003d\"UTF-8\"?\u003e\\n\u0027)"}],"source_content_type":"text/x-python","patch_set":1,"id":"9ff9d39b_4eb99646","line":1496,"updated":"2026-08-13 08:18:34.000000000","message":"so this would address the issue but feels like it is reversing the original intent of heartbeats (see https://review.opendev.org/c/openstack/swift/+/575818) which is to start feeding clients something *soonish*.\n\nthe commit for https://review.opendev.org/c/openstack/swift/+/575818 has some s3 docs saying that AWS will return 200 followed by an error in the body, (I found it here https://docs.aws.amazon.com/AmazonS3/latest/API/API_CompleteMultipartUpload.html)\n\nSo its ok for us to continue to do that, and we *shuld* continue to send heartbeats  for te reason that doc states: to repvent connection timeouts.\n\nMy primary concern is that the client gets a consistent response regardless of internal timing. This proposal would ensure the client always gets a 400, but risks connection timeouts, the alternative is to ensure they always get a 200 followed by an error in the body.","commit_id":"1b2c0c1c9aad133c6e8af416f00b7015d1023985"}]}