Error responses from certain operations do not conform to ODataV4

[fhoy]

• Package Name: azure-mgmt-web
• Package Version: 2.0.0
• Operating System: n/a
• Python Version: n/a

Describe the bug
Certain server-side failures produce error responses that do not conform to ODataV4, which means that the standard handling drops error details.

To my understanding, the OData section on error handling requires keys (code, message, etc.) to be lower-case, and the SDK code that parses error responses is implemented as such. However, in certain situations, we have observed the error responses to return title-cased keys (Code, Message, etc.), which causes the parsing code to raise a ValueError. A specific example is the following, that was returned when a call to web_apps.create_or_update_swift_virtual_network_connection() (using the default API-version, 2020-09-01), resulted in a 409 Conflict:

{"Code":"Conflict","Message":"Subnet X in VNET Y is already occupied by service S.","Target":null,"Details":[{"Message":"Subnet X in VNET Y is already occupied by service S."},{"Code":"Conflict"},{"ErrorEntity":{"ExtendedCode":"55914","MessageTemplate":"Subnet {0} in VNET {1} is already occupied by service {2}.","Parameters":[X,Y,S],"Code":"Conflict","Message":"Subnet X in VNET Y is already occupied by service S."}}],"Innererror":null}

Interestingly enough, forcing an error through running web_apps.get_swift_virtual_network_connection() and giving a non-existing service name leads to a 404 Not Found, with a correctly formatted response.

To Reproduce
Call web_apps.create_or_update_swift_virtual_network_connection() (using the default API-version, 2020-09-01) with a setup that results in a 409 Conflict.

Expected behavior
The error response conforms to the OData spec, for all operations.

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @antcp, @AzureAppServiceCLI.

Issue Details

---

• Package Name: azure-mgmt-web
• Package Version: 2.0.0
• Operating System: n/a
• Python Version: n/a

Describe the bug
Certain server-side failures produce error responses that do not conform to ODataV4, which means that the standard handling drops error details.

To my understanding, the OData section on error handling requires keys (code, message, etc.) to be lower-case, and the SDK code that parses error responses is implemented as such. However, in certain situations, we have observed the error responses to return title-cased keys (Code, Message, etc.), which causes the parsing code to raise a ValueError. A specific example is the following, that was returned when a call to web_apps.create_or_update_swift_virtual_network_connection() (using the default API-version, 2020-09-01), resulted in a 409 Conflict:

{"Code":"Conflict","Message":"Subnet X in VNET Y is already occupied by service S.","Target":null,"Details":[{"Message":"Subnet X in VNET Y is already occupied by service S."},{"Code":"Conflict"},{"ErrorEntity":{"ExtendedCode":"55914","MessageTemplate":"Subnet {0} in VNET {1} is already occupied by service {2}.","Parameters":[X,Y,S],"Code":"Conflict","Message":"Subnet X in VNET Y is already occupied by service S."}}],"Innererror":null}

Interestingly enough, forcing an error through running web_apps.get_swift_virtual_network_connection() and giving a non-existing service name leads to a 404 Not Found, with a correctly formatted response.

To Reproduce
Call web_apps.create_or_update_swift_virtual_network_connection() (using the default API-version, 2020-09-01) with a setup that results in a 409 Conflict.

Expected behavior
The error response conforms to the OData spec, for all operations.

Author:	fhoy
Assignees:	-
Labels:	App Services, Mgmt, Service Attention, customer-reported, question
Milestone:	-

[kristapratico]

Thanks for your question, we'll investigate and report back.

[BigCat20196]

Hi @fhoy Thanks for the feedback!

The latest azure-mgmt-web version is 3.0.0. In this version, create_or_update_swift_virtual_network_connection_with_check operation replaces create_or_update_swift_virtual_network_connection operation.

It is recommended to upgrade the version and try again. The problem may have been fixed.

Please kindly let us know if it solves the issue.

[ghost]

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

[ghost]

Hi @fhoy. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[ghost]

Hi @fhoy, since you haven’t asked that we “/unresolve” the issue, we’ll close this out. If you believe further discussion is needed, please add a comment “/unresolve” to reopen the issue.