Open klesta490 opened 1 year ago
Thank you for your feedback. This has been routed to the support team for assistance.
Any update?
Adding Service team to look into this.
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.
Hello, any update? Is anyone there? @jsquire
@klesta490: I apologize that this has not been followed-up on. Unfortunately, I do not have direct insight here. We'll need the folks that own the Storage library to offer thoughts.
//cc: @seanmcc-msft, @amnguye //fyi: @schaabs
Hello, is there any progress? @jsquire
@mkopsa-quadient : The answer is the same as the one right above your comment. This is not an issue that I will have insight on and requires the owners of the issue to offer thoughts.
OK. Can @seanmcc-msft or @amnguye answer?
Library name and version
Azure.Storage.Blobs 12.13.1.0
Describe the bug
When using
Because of missing
DisposeAsync
implementation inBlockBlobWriteStream
, generic implementation is called onStream
base class. This implementaiton calls syncDispose()
witch consequently callsFlush()
- synchronous https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/storage/Azure.Storage.Common/src/Shared/StorageWriteStream.cs#L227and in this
FlushInternal
there is StagingBlock if needed. And then block ids are always commited. - synchronous https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/storage/Azure.Storage.Blobs/src/BlockBlobWriteStream.cs#L87There is no way to avoid it, if I manually call
FlushAsync()
beforeDisposeAsync()
, then inFlushInternal
no blocks are staged, but I cannot avoid synchronous call for commiting block ids.Am I missing something?
Expected behavior
DisposeAsync is properly implemented, so there is no sychronous call when using async API.
Actual behavior
DisposeAsync
is not implemented/overriden, so whenDisposeAsync
is called, sychronous call from Stream base class to store block ids is done.Reproduction Steps
Environment
No response