azure-sdk-for-net
azure-sdk-for-net copied to clipboard
Azure
[FEATURE REQ] Add `BlobBaseClient.DownloadContentIfExistsAsync` API
Library name
Azure.Storage.Blobs
Please describe the feature.
We receive frequent requests for Orleans applications to not log exceptions when we attempt to access a blob which does not yet exist. These exceptions are being logged by APM software which are monitoring first-chance exceptions, such as Application Insights.
We would like an API to download blob content (i.e, 'BlobBaseClient.DownloadContentAsync`) which does not throw any exceptions (handled internally or otherwise) if the blob does not exist. We would like the opportunity to check for existence ourselves, so that we can handle the not-found case ourselves.
For example, the API could be BlobBaseClient.DownloadContentIfExistsAsync to clearly specify this behavior. I believe this is a common case and for performance reasons we would prefer not to have to perform an initial ExistsAsync probe (plus, ExistsAsync throws internally today. See: https://github.com/Azure/azure-sdk-for-net/issues/18592).
If you have an alternative that would obviate the need for such an API, please let us know. Thank you
@tg-msft, @annelo-msft : With the error classification changes now in Core, is it possible to configure the pipeline to opt-out of 404s for these scenarios?
There are a few options here - one is to expose DownloadContentIfExists as asked; we could also expose an overload of DownloadContent that takes a RequestContext or a protocol method for the service API.
It would be up to the library owner/architects which direction to go with the public API, but I know there was thinking that adding overloads that take RequestContext would be goodness to prevent an explosion of the API surface area.
Once you have a method that takes RequestContext, a caller can either set ErrorOptions.NoThrow to prevent an exception from being thrown from the service method, or add a classifier to indicate to the pipeline that 404 isn't an error response, which would also prevent errors from being logged, or distributed tracing from sending errors to app insights.
I'd personally lean toward not adding IfExists methods for these cases and instead expose RequestContext to avoid adding more overload choice. It would be more work than other examples like BlobContainerClient.CreateIfNotExists because whichever approach we take will require threading a RequestContext through parallel download.
Upvoting this request. We have built a generic settings storage service on top of Azure Blob Storage where client applications are only storing settings changed from default values. As such we have 70% of get requests to blob storage getting RequestFailedException exception from SDK with 404 response code. Throwing exception in majority of our API calls has a big impact on performance and CPU consumption of the service. Would really help to have any option to get 404 response without exception.
Is there any more information we can provide to help arrive at a solution here? For the record, the RequestContext idea sounds fine to me.
