Complex schema nesting silently breaks schema reference

Bug Report
1

I have schemas referencing / extending other schemas.

If I do a anyOf of a schema that itself contains another reference to a schema

image
image1530×604 111 KB

the openapi 3.0 spec fails silently :warning: and just returns an empty object.

- anyOf:
            - type: object
              properties: {}
            - type: object
              properties: {}
            - type: object
              properties: {}
            - type: object
              properties: {}
            - type: object
              properties: {}
            - type: object
              properties: {}
            - $ref: '#/components/schemas/CoverageTypeAddress'

If I remove the problematic Address in my example, then all seems OK.

image
image835×477 40.8 KB

       - anyOf:
            - $ref: '#/components/schemas/CoverageTypeAccounts'
            - $ref: '#/components/schemas/CoverageTypeUndefined'
            - $ref: '#/components/schemas/CoverageTypeHousehold'
            - $ref: '#/components/schemas/CoverageTypeBike'
            - $ref: '#/components/schemas/CoverageTypeHouseholdBikes'
            - $ref: '#/components/schemas/CoverageTypeCar'
            - type: object
              properties:
                type:
                  type: string
                  description: Type is always "address"
                  enum:
                    - address
                  x-apidog-enum:
                    - value: address
                      name: ''
                      description: ''
                description:
                  type: string
                  description: >-
                    Describes the coverage with a formatted text in the right
                    language
              x-apidog-refs: {}
              x-apidog-orders:
                - type
                - description
              required:
                - type

Now, just a rant :
This kind of behavior should REALLY not happen. The CORE feature of ApiDog is to ensure that we can design APIs, and to ensure that the import and export of OAS specifications is seamless so that it can be used as a reference for integration with other API management tools.

All of the other stuff about MCP servers and AI generation and testing capabilities and documentation features should be secondary. Take a step back and fix all of the problems around OAS exports for a sprint before commiting to nice-to-have features. For example, OpenAPI export generates invalid OpenAPI spec - #11 by YoamTCS is not fixed since 1 year ! ALL of your exports are not OAS compliant because of that since this time.

I wish there was an alternative solution on the market because to be honest your sense of priorisation does not make sense to me.

2

Hello YoamTCS,

Thank you for your detailed feedback. We highly value the point you raised regarding OpenAPI specification compliance.
We have marked this issue as the top priority, and the development team is already following up to quickly locate and resolve the problem.

1 Like
3

Do you have an ETA? This bug is heavily impacting our workflow and right now we are back at using a manual swagger editor to fix these invalid exports.