put_block method has no return type

Which service(blob, file, queue) does this issue concern?

Block blob

Which version of the SDK was used? Please provide the output of pip freeze.

azure-common==1.1.16 azure-storage-blob==1.4.0 azure-storage-common==1.4.0

What problem was encountered?

put_block() returns None, which makes leveraging the Azure Storage SDK with libraries like concurrent.futures difficult, as we end having to have a side-channel for state like block IDs.

Consider having put_block() return at least the block ID on a successful call, so that it can be tracked when consolidating the results from a worker thread pool.

Have you found a mitigation/solution?

Yes, but it’s ugly (add side effects to the code initiating the concurrent requests to modify a global state, read and clear that shared state upon commit)

Notes

As a side-note, calling get_block_list() after calling put_block() showed no uncommitted blocks. Is that the expected behavior?

[rickle-msft]

@zezha-msft I think the idea is that if I stage blocks C, A, B in that order, a common scenario is that I intend to commit them in that order as I’m likely uploading pieces of an object as I process it sequentially. If I were to do a get block list, though, I’d get blocks in the order A, B, C, and if I were to simply commit that block list, I would have reordered the contents of my blob in a potentially unintelligible way. Knowing the intended order of blocks then becomes the burden of the client and may require extra state.

@stewartadam your confusion is understandable, and we can ask about getting the documentation updated. Note, however, that an equally common scenario is that blocks are being uploaded in parallel and therefore the order in which they are staged really is no indication of their actual ordering to form a whole blob in that case and simply calling a getBlockList and commitBlockList would be equally unsafe no matter how the service chose to order them. As you pointed out, best practice is for the client to keep track of the block list locally and commit that list when uploads are finished. Please let us know if you have any difficulty with that.

[rickle-msft]

@stewartadam Thank you for that feedback. We will pass that on to those in charge of our docs. I’ll close this issue now as it seems your questions and concerns have been addressed, but please feel free to reach out with any other concerns you have.