Azure block blob uncommited update behavior

Question

I am writing a project that needs concurrent update to the block blob. From Microsoft documentation:

Uncommitted Block List: The list of blocks that have been uploaded for a blob using Put Block, but that have not yet been committed. These blocks are stored in Azure in association with a blob, but do not yet form part of the blob.

I could not find any documentation on

1. Whether an update on uncommitted blob could/should be performed
2. What happens when you write to an uncommitted blob.
3. How long is the time bound on a block blob to go from uncommitted -> committed based on the consistency policy you choose.

Could someone provide more context on the concurrent update behavior of uncommitted block blobs?

Answer 1

I tested it with fiddler, and the latest blob storage nuget package Microsoft.Azure.Storage.Blob, version 11.1.0

When you're using UploadFromByteArray method to upload to azure blob storage, there're some scenarios:

1.The files(or bytes array) are not big, like 10M or 100M, then there is no uncommitted status for the blob. In this case, by default, the concurrency policy "last writes win" apply. So here, you don't need to worry about uncommitted thing.

2.If the files(or bytes array) are big, like 200M, when you use UploadFromByteArray method, it will split into many blocks with a unique block id.

In this case, when the blob is uncommitted(before it calls put block list api), you can not perform another write operation for the blob. If you have a 2nd write operation, there is a error message "The specified blob or block content is invalid." for the 2nd write operation. I tested this, you can see the screenshot below:

Regarding your 3rd question, as per my test, when the status changes from uncommitted(when using put block api) -> committed(when using put block list), with the help of fiddler, I calculate the time is very short, less than 1s:

Hope it helps.