[core-client] Check response body for error details even without default body mapper

[jeremymeng]

Currently, when we receive an error response and there is no default body mapper, we immediately throw a
RestError without further inspecting the response body. It's ideal for operation specifications to define a
default mapper for unexpected responses. However, some services did not implement this leading to issues like
#33035 where the error message contains a JSON string of the
error object, and the error code is undefined.

This PR modifies the behavior to look into parsedBody if it has an 'error' property that contains both
'code' and 'message' properties, improving the developer experience in this scenario.

[azure-sdk]

API change check

API changes are not detected in this pull request.

[deyaaeldeen]

As a tangent, I recommend checking out the discussion in the email thread "Error parsing in Azure-Core" in May 2023.

This fix addresses the immediate customer ask. I don't have data on how many of our supported libraries still use this client but if it is significant enough, I wonder if we want to generalize the fix based on the discussion in the thread.

Also, the spec says that the x-ms-error-code header should have the error code, I wonder if we should look at that header if we can't find the code in the body.

[jeremymeng]

As a tangent, I recommend checking out the discussion in the email thread "Error parsing in Azure-Core" in May 2023.

Thanks for the point! I rechecked. The email thread was about supporting the two format of response body, one with the error wrapping object and the other without, which we already support in JS, but currently we return earlier before that supporting code because there's no matching operation spec.

This fix addresses the immediate customer ask. I don't have data on how many of our supported libraries still use this client but if it is significant enough, I wonder if we want to generalize the fix based on the discussion in the thread.

We may not need this fix for now if the service can update their specs to include the default response mapper.

[deyaaeldeen]

Also, related to this, I just received a 401 response from the Azure Foundry service that looks like this:

{
    statusCode: 401,
    message: 'Unauthorized. Access token is missing, invalid, audience is incorrect (https://cognitiveservices.azure.com), or have expired.'   
}

This is problematic because not only it doesn't conform to the Azure error response design, it also doesn't have a code at all. To make things worse, it also doesn't have an x-ms-error-code header.

[jeremymeng]

This is problematic because not only it doesn't conform to the Azure error response design, it also doesn't have a code at all. To make things worse, it also doesn't have an x-ms-error-code header.

Was the error from Azure Foundry, or from Microsoft Graph/Entra which may have a different design?

[deyaaeldeen]

Was the error from Azure Foundry, or from Microsoft Graph/Entra which may have a different design?

@jeremymeng, it was an Azure Foundry API (https://.services.ai.azure.com/models/chat/completions?api-version=2024-05-01-preview).