Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource manager statusMessage property has incorrect type. #2355

Closed
jhendrixMSFT opened this issue Jan 29, 2018 · 6 comments
Closed

Resource manager statusMessage property has incorrect type. #2355

jhendrixMSFT opened this issue Jan 29, 2018 · 6 comments
Assignees

Comments

@jhendrixMSFT
Copy link
Member

In https://github.com/Azure/azure-rest-api-specs/blob/master/specification/resources/resource-manager/Microsoft.Resources/stable/2017-05-10/resources.json#L2068. The property statusMessage is defined as object however the service doesn't always return an object (sometimes a string). This results in broken behavior for the Go SDK. The type must be either a string or an object and the service must abide by the specified contract. See Azure/azure-sdk-for-go#938 for more details.

@jhendrixMSFT
Copy link
Member Author

After recent discoveries in JSON schema I believe the correct thing to do here is remove the "type" so that statusMessage is treated as a wildcard type. @olydis @fearthecowboy do you agree?

@fearthecowboy
Copy link
Member

I believe that should be the case; I think we're still waiting for everyone to fix the generators to get the right behavior everywhere.

@jhendrixMSFT
Copy link
Member Author

Do we need to wait for that before updating the swagger?

@fearthecowboy
Copy link
Member

@olydis is going to verify that there isn't any breaking change to the code model if you do this now.

@olydis
Copy link
Contributor

olydis commented Feb 13, 2018

Confirmed: The current modeler (the one that does not handle object types properly) generates identical output for type: object vs no type on statusMessage, so indeed it can be safely removed without inducing breaking changes across existing generators. That was what my assumption, but wanted to confirm 😋

@zhenglaizhang
Copy link
Contributor

Looks like the issue is fixed in #2486, I will close it, if any guys has concern or questions, pls reopen it. thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants