Skip to content

[Regression from 2.0.20 to 2.0.21] Resolving of nested schemas within bodies #1599

@AML14

Description

@AML14

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions