-
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
Microsoft.DigitalTwins - add stable data-plane API version 2022-05-31 #18790
Microsoft.DigitalTwins - add stable data-plane API version 2022-05-31 #18790
Conversation
…21-06-30-preview to version 2022-05-31
…05-31' of https://github.com/sjiherzig/azure-rest-api-specs into dev-digitaltwins-Microsoft.DigitalTwins-dataplane-2022-05-31
Hi, @sjiherzig Thanks for your PR. I am workflow bot for review process. Here are some small tips. Any feedback about review process or workflow bot, pls contact swagger and tools team. [email protected] |
[Call for Action] To better understand Azure service dev/test scenario, and support Azure service developer better on Swagger and REST API related tests in early phase, please help to fill in with this survey https://aka.ms/SurveyForEarlyPhase. It will take 5 to 10 minutes. If you already complete survey, please neglect this comment. Thanks. |
Swagger Generation Artifacts
|
Hi @sjiherzig, Your PR has some issues. Please fix the CI sequentially by following the order of
|
To help drive the review, here is a summary of the changes from the previous version (2021-06-30-preview):
|
Note: I don't know what to do about the ModelValidation failure. We have used an "object" return type in the past, since the API response greatly depends on a model defined by the customer. |
@jianyexi for ModelValidation failure. At least the error message does not make sense for INVALID_TYPE. |
"required" in schema should be done like this: Lines 1245 to 1248 in 6d6b7c1
|
This has now been addressed. |
One thing to note - I've removed the "readyOnly" attribute from the error response model parameters because one of the automated validation tools complained that a required property should not be readyonly. This doesn't quite make sense to me - doesn't readonly set only the context whether it is from a response or a request? Should / can this be fixed? |
@sjiherzig Our guide https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md#handling-errors and some SDK weight more on "required", as in this particular case, "readonly" of the whole "Error" schema can be deduced (as "Error" is not used as input in any operation). In this case, maybe not adding the "required" is the preferred compromise, as it keep it same as your last GA api-version. |
Please also note that the guideline asks for the "x-ms-error-code" header on error response. Please do evaluate whether it can be included in this api-version (it requires backend change). If yes, please support it; if not, please open a backlog item in your service to add it in next api-version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
skip ModelValidation CI, as it is intended for digitaltwin having response schema of type=object
Hi @weidongxu-microsoft - this is now ready to be merged! |
Do we have an issue relates to the PR? I didn't remember since it is a long time ago. It is possible you do not have the issue and meeting notes, as there is no API change since last version. |
@weidongxu-microsoft Yes, there is a GitHub issue for this PR: #18792 . There are no outstanding action items for the PR. The review was done asynchronously. |
MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.
Changelog
Add a changelog entry for this PR by answering the following questions:
Contribution checklist:
If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist
Otherwise your PR may be subject to ARM review requirements. Complete the following:
Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.
Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.
If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.