beinan opened a new issue, #885: URL: https://github.com/apache/arrow-rs-object-store/issues/885
Azure multipart completion is marked idempotent, but its serialized block list uses `<Uncommitted>`. If the service commits the block list and the client loses the success response, the SDK retries the same request after those block IDs have moved into the committed block list. Azure then returns HTTP 400 `InvalidBlockList`, despite the object already being written successfully. Reproduction: 1. Upload two blocks through `MicrosoftAzure::put_multipart`. 2. Forward the completion request to Azure. 3. After receiving and consuming the successful response, inject a client timeout instead of returning that response to the SDK. 4. Let the SDK retry completion normally. With object_store 0.13.2 against a real Azure test object, the retry returns `InvalidBlockList`. The object reads back with the exact expected payload. Changing the block-list entries to `<Latest>` makes the same fault injection complete successfully on its second attempt, with exact payload readback. Test objects were deleted afterward. The current main branch also serializes `<Uncommitted>`. [Azure Put Block List documentation](https://learn.microsoft.com/en-us/rest/api/storageservices/put-block-list) specifies that `Latest` searches the uncommitted block list first, then the committed list. The SDK uses random block IDs for each part, so completion can refer to the same upload's blocks after a lost response. Expected behavior: a retried completion can use those already committed blocks. Actual missing blocks should still fail; this does not call for retrying arbitrary HTTP 400 responses or re-uploading parts. -- 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]
