Error handling in storage SDKs

[XiaoningLiu]

Is your feature request related to a problem? Please describe.

Using @azure/storage-blob and other storage SDKs. We need to catch errors when invoking storage async APIs. However, the errors caught doesn't parser x-ms-error-code and other Azure Storage error message or descriptions from returned HTTP body. For example, when getting properties from non exist blob.

    try {
      await blobClient.getProperties();
    } catch (err) {
      console.log(err);
    }

We need to retrieve the raw headers to get storage error code by err.response.headers.get("x-ms-error-code").

Describe the solution you'd like
A clear and concise description of what you want to happen.

Storage SDK uses protocol layer code generated by autorest-typescript from swagger. The swagger already defines how to parser storage error responses. But the generated code doesn't return errors defined in swagger.

The error thrown should parser error responses and fits the swagger definition correctly. For example, parser ErrorCode from x-ms-error-code header value.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Workaround is to wrap and handling the error parse in storage SDK side. But it's against the initial design about deserializtion should be done in protocol layer - generated code.

Additional context
Add any other context or screenshots about the feature request here.

[YoDaMa]

This is related to the issue filed in the autorest repo: Azure/autorest.typescript#464

[YoDaMa]

Is there an eta on when this will be sorted out?

[XiaoningLiu]

@ramya-rao-a Typescript generator related, please take a look.

[YoDaMa]

I think this is related to this issue, but the BlobUploadCommonResponse interface has no parameter with a statusCode description. The status code can be found with uploadResponse._response.statusCode but the most suitable value to have a description of the statusCode, which would be bodyAsText, always is empty. See on a successful call to BlobUploadCommonResponse:

let uploadStatus = await uploadStreamToBlockBlob(
      Aborter.timeout(30 * 60 * 1000), // Abort uploading with timeout in 30mins
      fs.createReadStream(localFilePath),
      blockBlobURL,
      4 * 1024 * 1024, // 4MB block size
    20, // 20 concurrency
);
let isSuccess = true;
let statusCode = uploadStatus._response.statusCode; // will be 201
let statusDescription = uploadStatus._response.bodyAsText;  // will be empty

[ramya-rao-a]

We will follow up on the code generator side first and then come back here with an update
cc @jeremymeng & @sarangan12

[jeremymeng]

The fix needs changes from both code generator and the core-http run-time.

[ramya-rao-a]

In the latest version of the storage libraries (12.0.0-preview.5), the error object is updated as below

• The response property will have parsedBody and parsedHeaders along with the raw body and headers it already had
• A new property details is added on the error object. It is this property that will contain the error information in the data model as defined in the swagger specification. So storage library users will be able to do error.details.errorCode and error.details.message to get the error details

#5796 will handle pulling these details up to be top level properties on the error object.