unmarshalling JSON error in DeploymentOperationsClient.ListNextResults

[dmitsh]

Failure responding to next results request:

StatusCode=200 -- Original Error: Error occurred unmarshalling JSON - Error = 'json: cannot unmarshal string into Go struct field DeploymentOperationProperties.statusMessage of type map[string]interface {}' JSON = '{"value":[{"id":"/subscriptions/3014546b-7d1c-4f80-8523-f24a9976fe6a/resourceGroups/ds-acse-tst40/providers/Microsoft.Resources/deployments/agent-18-01-03T10.39.23-1324017081/operations/08586866021206228739","operationId":"08586866021206228739","properties":{"provisioningOperation":"EvaluateDeploymentOutput","provisioningState":"Failed","timestamp":"2018-01-03T18:41:51.0473602Z","duration":"PT0.5431112S","trackingId":"98f19b12-ae95-49db-953b-6c983868f5e4","statusCode":"Conflict","statusMessage":"Template output evaluation skipped: at least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details."}}]}'

By comparing JSON data with DeploymentOperationProperties, the latter

• doesn't have duration field
• has StatusMessage is a map, not a string

[jhendrixMSFT]

Swagger bug? The statusMessage field is defined as an object.

[jhendrixMSFT]

Here's the returned JSON in indented format.

{
  "value": [
    {
      "id": "/subscriptions/3014546b-7d1c-4f80-8523-f24a9976fe6a/resourceGroups/ds-acse-tst40/providers/Microsoft.Resources/deployments/agent-18-01-03T10.39.23-1324017081/operations/08586866021206228739",
      "operationId": "08586866021206228739",
      "properties": {
        "provisioningOperation": "EvaluateDeploymentOutput",
        "provisioningState": "Failed",
        "timestamp": "2018-01-03T18:41:51.0473602Z",
        "duration": "PT0.5431112S",
        "trackingId": "98f19b12-ae95-49db-953b-6c983868f5e4",
        "statusCode": "Conflict",
        "statusMessage": "Template output evaluation skipped: at least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details."
      }
    }
  ]
}

[jhendrixMSFT]

@vivsriaus Are you the owner of the resources swagger (I dug up your name from specs history)? I'm trying to understand why the statusMessage field is defined as object when it's coming across the wire as a string.

[vivsriaus]

@jhendrixMSFT yes, this is because the statusMessage property is defined as a JToken in ARM, and it could potentially contain an ErrorMessage object (with its own "Code", "Message", "Target", "Details", "Innererror" properties)

[jhendrixMSFT]

The problem here is that the server didn't return an object but a simple string which doesn't fit the definition. @amarzavery do you have any thoughts on this?

[jhendrixMSFT]

Ping @amarzavery.
@vivsriaus can you please clarify what you mean by "JToken in ARM". The swagger, which is supposed to be the source of truth, defines this field as an object. In this example it's clear that what was sent across the wire is not an object.

[vivsriaus]

@jhendrixMSFT Like I mentioned above, the statusMessage property in DeploymentOperation can either return a string (like the case above) or an ErrorMessage object. Shouldn't autorest consider this as an object (which will then allow string to be processed as well), instead of string?

[jhendrixMSFT]

I'm not an expert on the W3C spec but my understanding is that a JSON object is defined like this, so sending a simple string across the wire doesn't meet that definition.
CC @johanste

[johanste]

In swagger (and JSON schema), a string is not an object. You can mentally replace object with dictionary in most cases. It so happens to (accidentally) work in most languages simply due to strings pretty much always derive from object.

In this case, will the return type always be a string, or does it depend on the context?

[jhendrixMSFT]

OK that's what I thought and is in fact how we model JSON objects in Go.

map[string]interface{}

So it would seem that the service isn't honoring the contract defined in the swagger yes?

[vivsriaus]

To answer @johanste 's question, yes, the return type depends on the context. I'll try to find a real world example where an object is returned for a DeploymentOperation

[jhendrixMSFT]

@vivsriaus Any update?

[vivsriaus]

@jhendrixMSFT I'll talk to our team and see if we can make a fix to always return either a string or an object for DeploymentOperationProperties.StatusMessage. Like I mentioned, currently, the statusMessage type returned depends on the context. I'm not sure if this is a common scenario in other object models, but it looks like autorest currently doesn't have a way to work with both types (string and object) at the same time.

[jhendrixMSFT]

This is not an autorest issue. What you're asking for cannot be modeled in swagger as string and object are fundamentally different types.

[jhendrixMSFT]

This should be fixed in v14.0.0. The statusMessage field is now defined as interface{} so you will need to perform type assertion to determine if it's a string or JSON object.