-
Notifications
You must be signed in to change notification settings - Fork 14
CLOUDP-304938: Adds rule xgen-IPA-105-list-method-response-is-get-method-response #535
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
Conversation
| } | ||
| return path; | ||
| } | ||
|
|
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.
Moved to methodUtils
| return null; | ||
| } | ||
|
|
||
| const versions = Object.keys(response.content); |
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.
Added version matching here used in both getResponseOfListMethodByMediaType and getResponseOfGetMethodByMediaType
| xgen-IPA-105-list-method-response-is-get-method-response: | ||
| description: >- | ||
| The response body of the List method should consist of the same resource object returned by the Get method. Validation checks that the List method results items reference the same schema as the Get method response.<br/> | ||
| - Validation applies to List methods for resource collections only<br/> |
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.
As far as I understand:
- Validation makes schemaName level comparison only
- Validation also does not make inline schema comparison
Are these assumptions correct? If so,
List-Get relationship is strict, so I am okay with expecting exactly the same schema.
Do we assume Get response always has schema reference, and should we consider inline schemas?
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.
Validation makes schemaName level comparison only
Yes, it checks that it refers to the exact same schema
Validation also does not make inline schema comparison
The paginated schema can be inline, but the resource schema itself is expected to be a schema ref, if the get doesn't have a ref, there will be a violation. I can add a test to cover this to make sure
| } | ||
|
|
||
| // Ignore if the List method does not have a response schema | ||
| const listMethodResponse = getResponseOfListMethodByMediaType(mediaType, resourcePath, oas); |
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.
Why do we call this method? Isn't the rule iterating list method response content already?
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.
Good catch, we can just get the response, I'll update 👍
| function: 'eachResourceHasListMethod' | ||
| xgen-IPA-105-list-method-response-is-get-method-response: | ||
| description: >- | ||
| The response body of the List method should consist of the same resource object returned by the Get method. Validation checks that the List method results items reference the same schema as the Get method response.<br/> |
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.
That is based on assumption that "list operations" return pagginated objects - with results, total etc.
I seen that one before. Would we have validation and helper to check for that assumption each rule can base on it?
| The response body of the List method should consist of the same resource object returned by the Get method. Validation checks that the List method results items reference the same schema as the Get method response.<br/> | |
| The response body of the List method should consist of the same resource object returned by the Get method. Validation checks that the List method response contains items property with reference the same schema as the Get method response.<br/> |
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.
I really like that I can see how you interpreted the rule inside the PR. Saves us back and forth with code based discussion.
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.
Yes this one only applies to paginated lists (we ignore if it's not paginated). We will have another IPA to cover pagination in general
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.
@lovisaberggren Yes. I'm aware. My intention for this comment was to add note to the yaml/docs.
| } | ||
|
|
||
| // Ignore if the List method response is not found or not paginated | ||
| if (!resolvedListSchema || !schemaIsPaginated(resolvedListSchema)) { |
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.
Unrelated to the PR but helper implementation might need additional checks as it now based on weak assumption that property named results means paggination. This logic should be covered in the rule description etc.
e.g "Pagginated property is determined by object returning results property with type array or something like this.
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.
IMHO we should at least check if results type is array
return fields.includes('properties') && Object.keys(schema['properties']).includes('results');
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.
Yeah, I'll add a note in the description, and also add a check that the results is an array
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.
Awesome. Second comment can be follow up jira as you haven't introduced that helper in this PR
| } | ||
|
|
||
| // Ignore if the List method does not have a response schema | ||
| const listMethodResponse = oas.paths[resourcePath].get.responses['200'].content[mediaType]; |
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.
| const listMethodResponse = oas.paths[resourcePath].get.responses['200'].content[mediaType]; | |
| const listMethodResponse = resolveObject(documentInventory.resolved, path); |
| return [ | ||
| { | ||
| path, | ||
| message: `Could not validate that the List method returns the same resource object as the Get method. The Get method does not have a schema.`, |
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.
Q: Should we return the same error for the createMethodRequest comparison?
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.
Sure, that makes sense 👍
| function: 'eachResourceHasListMethod' | ||
| xgen-IPA-105-list-method-response-is-get-method-response: | ||
| description: >- | ||
| The response body of the List method should consist of the same resource object returned by the Get method. http://go/ipa/105 |
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.
Link to IPA is no longer needed as it is already part of the docs and in failure we do reference to the docs in open source repo
| The response body of the List method should consist of the same resource object returned by the Get method. http://go/ipa/105 | |
| The response body of the List method should consist of the same resource object returned by the Get method. |
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.
Meta comment/ Not this PR/Project:
In retrospect we could use public shortener to link to this repo to be kind for non MongoDB use cases.
Technically you could make blog post covering new mongodb validations and then go links will be the only blocker. All the info will be availabile upstream.
This can be addressed once we get our plans around IPA publication done.
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
All comments are nits.
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! Thanks!
Proposed changes
Adds rule
xgen-IPA-105-list-method-response-is-get-method-responsewhich checks that the paginated List method results reference the same schema as the resource Get method. Also handles version matching, which affected the existing rulexgen-IPA-106-create-method-request-body-is-get-method-response.New rule
xgen-IPA-105-list-method-response-is-get-method-responsehas 2 violationsExisting rule
xgen-IPA-106-create-method-request-body-is-get-method-responsehas one new violationI'll do follow-up to add exceptions to both above
Added tests for the rule and unit tests for the functions used to get the responses based on a version.
Jira ticket: CLOUDP-304938