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
When defining an enum within the components/schemas section of the openapi schema, it results in a crash. One would do this as to reuse the enum or simply return an array of enum values inside a property. The reason for this crash is the following:
Given is the following schema:
openapi: 3.0.3components:
schemas:
Example:
type: objectproperties:
nestedEnum:
type: stringenum:
- A
- B
- CFruit:
type: stringenum:
- Apple
- Orange
- Pear
We have a nestedEnum which is defined within an additional schema, while the Fruit enum itself is a top-level schema. This will produce the following resolved definitions:
The problem here, I believe, is that Fruit is a schema and as such causes not only the FruitFruit#EnumTypeSuffix to be created, but also itself gets inserted as a regular schema into the resolved definitions. This is done by the DefinitionsResolver regardless of the type of schema. This later on causes an error when the resolver fails to do so. In addition to this, there seems to be a naming issue in this circumstance, as seen by the name FruitFruit#EnumTypeSuffix which results in an enum named FruitFruit.
When defining an enum within the
components/schemas
section of the openapi schema, it results in a crash. One would do this as to reuse the enum or simply return an array of enum values inside a property. The reason for this crash is the following:Given is the following schema:
We have a
nestedEnum
which is defined within an additional schema, while theFruit
enum itself is a top-level schema. This will produce the following resolved definitions:The problem here, I believe, is that
Fruit
is a schema and as such causes not only theFruitFruit#EnumTypeSuffix
to be created, but also itself gets inserted as a regular schema into the resolved definitions. This is done by the DefinitionsResolver regardless of the type of schema. This later on causes an error when the resolver fails to do so. In addition to this, there seems to be a naming issue in this circumstance, as seen by the nameFruitFruit#EnumTypeSuffix
which results in an enum namedFruitFruit
.I have formulated my proposed changes in a PR #8
The text was updated successfully, but these errors were encountered: