-
Notifications
You must be signed in to change notification settings - Fork 527
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
[Regression from 2.0.20 to 2.0.21] Resolving of nested schemas within bodies #1599
Comments
We also have this issue. The OpenAPI Generator using this parser version (since 2.0.21) generates incorrect code for our API definition |
hi!, thanks for reporting this issue, I'm trying to reproduce this with tag v2.0.20 and haven't been able to hit the option combo like you described. Can you please send a scenario of how are the options called, and if the method is indeed read(). also the definition is 2.0, so I guess the idea is to convert it. So far it returns an openApi fully resolved, with not references in the path /pet. Can you please share the expected output of path /pet and schema pet. Thanks |
If what you need is this
Then you can remove the flatten(true) option, and remain with a fully resolved definition. Please let me know if this is what's needed. |
closing as inactive |
For some time, we've been using version 2.0.20 of this library. When we updated to 2.0.21 (actually 2.0.27, so the issue still persists), we noticed the following misbehavior:
Although as stated in #1538 there is no way to resolve nested schemas within the same OpenAPI, there used to be a way in 2.0.20, like this:
If we parse the Petstore Swagger (located here), this code yields two different OpenAPI objects depending on the version. For example, if we look at the property
this.specification.paths.get("/pet").post.requestBody.content.get("application/json").schema
, this is what we get:category
property in the screenshot below).type
andproperties
are null, and whose$ref
attribute points to a newly-created-by-the-parser schema (#/components/schemas/pet_body_2
). At the same time, within this schema, thecategory
property is not resolved either, instead it points to another newly created schema (#/components/schemas/pet_category
).Please, I would greatly appreciate if you could properly implement this feature, originally requested in #1538, or at least bring back this behavior by combining those ParseOptions.
The text was updated successfully, but these errors were encountered: