[Python] LRO initial error response

[annatisch]

It seems that if an error occurs during a long running operation, it will either have an exit code of 200/201/202/204 and be deserializable to an object as defined in the swagger, or it will have a generic error code (e.g. 400) and have an error response in a format conforming to the Resource Provider spec.

Is it also expected behaviour to be able to fail with a standard exit code (400) and be able to deserialize that response to a swagger object?

Currently the Python runtime does not accommodate this - do the other languages?

This issue is encountered with the IoT spec documented in the issue here:
Azure/azure-rest-api-specs#488

[lmazuel]

To give more details, IoTHub is returning:

{
  "Code" : "IotHubsQuotaExceeded",
  "HttpStatusCode" : "BadRequest",
  "Message" : "Max number of Iot Hubs exceeded for sku = Free, Max Allowed = 1, Current = 2. If you contact a support representative please include this correlation identifier: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, timestamp: 2016-08-24 05:17:41Z, errorcode: IH400019."
}

while other services returns OData v4.0 error message syntax:

{ 
   "error": { 
      "code": "BadArgument", 
      "message": "The provided database ‘foo’ has an invalid username."
  }
}

Based on the RestAPI document I have, MS WebService are supposed to follow OData error message.

So, should we make an exception and support the IoTHub format, or ask the IoTHub team to follow the OData v4.0 convention as everyone else?

Python currently supports OData error message and does not parse message using the IoTHub format.

@amarzavery @tbombach @rkmanda

[xscript]

Any update? Now command module for IoT in Azure CLI (python) can't display error message from server, which doesn't help user to take proper actions to fix their errors.

[annatisch]

@amarzavery,
If I could just confirm what we discussed when this came up last week - I'm I correct in understanding that according to the schema here:
https://github.com/Azure/azure-rest-api-specs/blob/master/arm-iothub/2016-02-03/swagger/iothub.json#L103

The default error response should be used as higher priority than the OData error object when handling any non-200/201/202/204 exit code on the initial call (i.e. non during polling) - does this sound right?

[yugangw-msft]

Another issue on python LRO deserialization. It appears the 2 fields from LRO error are not being handled. If no specific reasons, we should fix it. Let me know if we need a separate bug.
I found this issue on app service plan creation code, python SDK reports a very generic exception because of this.

[annatisch]

Hi @yugangw-msft,
This error is specifically about poor deserialization on the initial response, as opposed to polling responses - if that's not what you're encountering it would be best to open a new issue.

Which version of msrestazure are you seeing this with? My changes to address this issue have been merged but not yet published, so if it's initial error deserialization that's incorrect you could try grabbing the latest azure_operations.py and seeing if that solves it:
https://github.com/Azure/autorest/blob/master/src/client/Python/msrestazure/msrestazure/azure_operation.py

[yugangw-msft]

It is on the poor deserialization on the initial response, but i would agree this can be tracked as a separate issue. It is a different thing though related.
And yes, I did try out your change yesterday, saw it doesn't work, debugged, and then realized python never sniffed the 'target' and detail fields :-)

[annatisch]

Woah yeah - I'm pretty sure the Python implementation of CloudError doesn't include Target or Details, so that is certainly a big issue, though agreed, a separate one. Thanks for finding this!!

[yugangw-msft]

Sure, opened #1460. Please let us know when you have a ETA on this
Thanks @annatisch!

[lmazuel]

Initial bug fixed by: #1451
Release soon

[lmazuel]

Released in msrestazure 0.4.4
https://pypi.python.org/pypi/msrestazure/0.4.4