You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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
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.
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: