Skip to content
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

Closed
AML14 opened this issue Aug 24, 2021 · 4 comments
Closed
Assignees

Comments

@AML14
Copy link

AML14 commented Aug 24, 2021

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:

ParseOptions parseOptions = new ParseOptions();
parseOptions.setResolve(true);
parseOptions.setResolveFully(true);
parseOptions.setFlatten(true);
this.specification = new OpenAPIV3Parser().read(path, null, parseOptions);

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:

  • In version 2.0.20: An object schema with some properties which, at the same time, are also fully resolved (for example, take a look at the category property in the screenshot below).
  • In version 2.0.21: A schema whose type and properties 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, the category 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.

Screenshot 2021-08-24 at 14 50 09

@LSeawalker
Copy link

We also have this issue. The OpenAPI Generator using this parser version (since 2.0.21) generates incorrect code for our API definition

@gracekarina
Copy link
Contributor

gracekarina commented May 23, 2022

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

@gracekarina
Copy link
Contributor

If what you need is this

In version 2.0.20: An object schema with some properties which, at the same time, are also fully resolved (for example, take a look at the category property in the screenshot below).

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.

@frantuma
Copy link
Member

closing as inactive

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants