arm/storage - CheckNameAvailability failed

[bingosummer]

I got the failue when I ran "go test" in arm/examples. But it worked a few days ago.

storage.StorageAccountsClient:CheckNameAvailability Failure responding to request -- Original Error: json: cannot unmarshal string into Go value of type bool

It seemed that the server responded with a wrong value.
https://github.com/Azure/azure-sdk-for-go/blob/master/arm/storage/storageaccounts.go#L71

[brendandixon]

@bingosummer Does this recur for you? I ran the tests this morning and worked as expected. The code does follow the API documentation (see https://msdn.microsoft.com/en-us/library/azure/mt163642.aspx). Unless there was some other error (e.g., network glitch, service sending a malformed response), it should be correct.

If this recurs, could you, please try to capture the JSON output? Thank you. Feel free to re-open then.

[brendandixon]

@bingosummer I should have left this open to better track. Re-opening.

[bingosummer]

It recurs.

I am new to Golang. I just printed resp and result just like the following, and got a output. Not sure if it is what you want.

err = autorest.Respond(
                        resp,
                        client.ByInspecting(),
                        autorest.WithErrorUnlessOK(),
                        autorest.ByUnmarshallingJSON(&result))
fmt.Println(resp.Body)
fmt.Println("NameAvailable: ", result.NameAvailable)
fmt.Println("Reason: ", result.Reason)
fmt.Println("Message: ", result.Message)

output:

&{0xc82036c0a0 {0 0} false <nil> 0x5318b0 0x531850}
NameAvailable:  false
Reason:
Message:
2015/09/11 03:22:17 Error: storage.StorageAccountsClient:CheckNameAvailability Failure responding to request -- Original Error: json: cannot unmarshal string into Go value of type bool

[bingosummer]

@brendandixon
My step is:

1. go get -d github.com/Azure/azure-sdk-for-go
2. edit ~/.azure/credentials.json
3. cd azure-sdk-for-go/arm/examples; go test

Then it failed.

[brendandixon]

@bingosummer Ok. Let's get some more information. In the examples/check.go file do the following:

1. Add imports for "io/ioutil" and "strings"
2. Add the following lines to the "ByInspecting" RespondDecorator just after the fmt.Printf statement:

b, _ := ioutil.ReadAll(resp.Body)
resp.Body.Close()
fmt.Printf("Body: %s\n", string(b))
resp.Body = ioutil.NopCloser(strings.NewReader(string(b)))

1. Then run "go test --run TestCheckName -v > output.txt"
2. Paste the output here (after editing out your subscription ID if you desire).

This will save the JSON returned from the Stroage call.

Ok?

[bingosummer]

@brendandixon I appreciate your help.
Output:

=== RUN   TestCheckName
Inspecting Request: POST https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Storage/checkNameAvailability?api-version=2015-05-01-preview
sdk-example: 2015/09/15 01:29:44 Sending POST https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Storage/checkNameAvailability?api-version=2015-05-01-preview
sdk-example: 2015/09/15 01:29:47 POST https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Storage/checkNameAvailability?api-version=2015-05-01-preview received 200 OK
Inspecting Response: 200 OK for POST https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Storage/checkNameAvailability?api-version=2015-05-01-preview
Body: {"nameAvailable":"true"}

exit status 1
FAIL    github.com/bingosummer/examples 2.675s

The value of "nameAvialable" is a string, which should be a bool. Is it the root cause of my failure?

[bingosummer]

I change the type of NameAvailable from bool to string, and everything is OK.
https://github.com/Azure/azure-sdk-for-go/blob/master/arm/storage/models.go#L79

IMO, the behavior of ARM REST API should be the same. I'm wondering why it only happens in my test environment.

[ahmetb]

@bingosummer turns out the Swagger API spec is misspecified hence the generated code is wrong: Azure/azure-rest-api-specs#19 it's bool vs string issue as you found out.

[bingosummer]

@ahmetalpbalkan Thanks for your confirmation.
This issue is quiet wired because it does work about two weeks ago.
in the last few weeks, Is there any change to the Swagger API spec or ARM REST API about the return value of NameAvailable?

[brendandixon]

@ahmetalpbalkan @bingosummer Something larger is amiss here. The service had been returning a boolean (despite the documentation). In fact, if I run this and print the JSON, I get a boolean:

=== RUN   TestCheckName
Inspecting Request: POST https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Storage/checkNameAvailability?api-version=2015-05-01-preview
sdk-example: 2015/09/15 09:28:11 Sending POST https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Storage/checkNameAvailability?api-version=2015-05-01-preview
sdk-example: 2015/09/15 09:28:12 POST https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Storage/checkNameAvailability?api-version=2015-05-01-preview received 200 OK
Inspecting Response: 200 OK for POST https://management.azure.com/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Storage/checkNameAvailability?api-version=2015-05-01-preview
Body: {"nameAvailable":true}
The name 'testname01' is available

Let me follow up.

[ahmetb]

@brendandixon let's start an internal thread with the product team. I can hardly imagine it's returning string for some users even though it's the same API version. I'm guessing this has been a string at some point in the past, that's what the docs are hinting partially.

[brendandixon]

@ahmetalpbalkan I already have. I agree the behavior is odd. However, it is occurring. I reliably get a boolean, not a string, and have received a boolean for some time. Frankly, I do not trust the documentation to this level of detail.

[brendandixon]

@bingosummer The service team would like to debug this further. To do so they need your subscription ID along with the full Request / Response. I can give you inspectors that will capture the Request / Response. To protect your subscription, perhaps you could send it to me directly? brendand at microsoft dot com. Ok?

[brendandixon]

@bingosummer My understanding is that the Service team resolved the issue for you? Is that correct? If so, let us know. Thanks.

[brendandixon]

@bingosummer Try again using #221

[bingosummer]

Yes. The issue is resolved. Thanks.