-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
Remove 4xx responses and change schema to file #3363
Conversation
Automation for azure-sdk-for-pythonThe initial PR has been merged into your service PR: |
Automation for azure-sdk-for-javaNothing to generate for azure-sdk-for-java |
Automation for azure-sdk-for-rubyThe initial PR has been merged into your service PR: |
Automation for azure-sdk-for-nodeThe initial PR has been merged into your service PR: |
Automation for azure-sdk-for-goThe initial PR has been merged into your service PR: |
@vrdmr could you provide some context on what does it mean "unblock the SDK serialization issue."? As for current status of your PR - you are introducing breaking changes to stable API version. |
@AutorestCI regenerate azure-sdk-for-go |
@hovsepm The serialization issue in dotnet SDK is mentioned in details here (slack link), but tl;dr is that Autorest generates code which expects the output schema to be json and we return file. This causes a serialization issues and is breaking out current SDK users (our SDK is still in the preview though). Thus, for |
@vrdmr the issue you pointed out in Slack channel is about "2017-05-15-preview" version - why do you have breaking changes in version 2015-10-31 which is marked as stable and I assume was shipped? |
@hovsepm The #2466 PR made the changes in bot 2015-10-31 (Runbooks) and 2017-05-15-preview (Jobs) resources. For the |
Ping @hovsepm. |
@vrdmr I'm asking about service response changes - in many places your change removes 409 return codes. These are new breaking changes in the existing stable API version. |
@hovsepm Yes, we are removing 409 here and other places as in the SDKs, they are being returned as successful and not generating exceptions, which they should. This was caught by @dsgouda in the AzureSDK PR. We do want exceptions being thrown for an error case, whereas currently, it would not raise for any. |
@vrdmr you do realize that there are many applications that are already shipped using API version 2015-10-31 that do use 409 as return code and have some logic to handle that return codes. Changing it to throw an exception will cause breaks for any patch in the code that will use latest generated SDK. I'd strongly suggest to change return types to exception only in the new/preview API version. |
@hovsepm Updated the Spec. Could you please review and merge this PR. Thanks, |
@vrdmr please fix model validation errors:
|
@vrdmr ignore the error. |
Removing the 4xx response codes and changing the schema from string to file to unblock the SDK serialization issue.
FYI: @najams @shahabhijeet
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information
api-version
in the path should match theapi-version
in the spec).Quality of Swagger