-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
.Net: fix: distincts parameters before building the OAS function #9840
Closed
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
OpenAPI specification allows for non-unique parameters in different parts of a REST request. For example, there may be operations where the parameter
Id
represents a user id in the path and a product id in the query string. It's also possible for theId
parameter in different parts of the request to represent a single domain concept, such as a user id.SK does not have enough information to distinguish between these different uses of the parameters with the same name. To address this issue, SK provides a customization mechanism that allows developers to handle such cases: HandleOpenApiDocumentHavingTwoParametersWithSameName....
Using only the first occurrence of a non-unique parameter may not be safe and can lead to data corruption, in cases when each instance represents a property of a different domain entity.
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.
Could we do distinct but composite key instead? Which would be name and location?
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.
The only reason, as far as I understand, to do so would be to get one parameter out of many with the same name in one location. I wonder if it's a valid scenario at all or just an OpenAPI document design/generation bug. Why would anyone have more than one parameter with the same name in a path, query string, header, etc.? And if we decide to do a distinct on the name-location composite key, why should we get the first parameter and not the second one? What if those non-unique parameters in the same location differ by schema, description, required, style, explode, and other properties of the Parameter Object? Which one should SK pick?
Scenarios like that should be handled using the SK OpenAPI customization capabilities and not by SK, because SK does not have enough information to make the right decision.
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.
Here is a scenario that breaks that assumption.
POST operation, with a graph message, which has an odata type property. It also has a body property, which itself has an odata type property.
Due to how the request body fields and subfields are mapped today, we end up with two odata type parameters in this collection.
The true fix would be to map the parameters with different names to reflect the nesting, but I'm not there yet in terms of how much overall of this code I can perform. Both in terms of mental mapping of the code base but also in terms of confidence a large work in this section will get accepted by the repository maintainers. (c.f. my previous PRs)
This is just an incremental step to:
I'm happy to put the distinct behind a configuration switch if guidance is provided. Also happy to tweak the distinct to use a composite key so we don't end up removing things with the same name from different places as mentioned earlier. I don't think this fix should be done outside of this method (e.g. proxy/decorator) since it ALL OpenAPI based functions.
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.
Can you please provide an example of an OpenAPI document with such a POST operation? Have you disabled dynamic payload construction by setting the
OpenApiFunctionExecutionParameters.EnableDynamicPayload
parameter to false? Have you tried to provide unique parameter names/arguments for non-unique parameters via customization, as suggested above and demonstrated by this sample - HandleOpenApiDocumentHavingTwoParametersWithSameNameButRelatedToDifferentEntitiesAsync?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.
Disabling dynamic payload generation: no, we'd like to conserve/improve this mechanism at this point.
Custom payload: for the same reason I did not explore this avenue, requiring customers to build the payload themselves when they are providing an OAS description defeats the point.
Example: there it is: observe the presence of odata type properties at multiple levels of the object tree.