Swagger-ui: allOf multiple level inheritance bug?

[mlubimow]

Q&A (please complete the following information)

• OS: osx sierra
• Browser: chrome
• Version: 67.0.3396.87 (Official Build) (64-bit)
• Method of installation: dist
• Swagger-UI version: 3.17.1 gitRevision":"ga6656ced"
• Swagger/OpenAPI version: Swagger 2.0

Content & configuration

Define four level inheritance like in my schema and try to use the last one

Example Swagger/OpenAPI definition:

    "definitions": {
            "profile_list": {
                "type": "object",
                "properties": {
                    "id": {"type": "integer"}
                }
            },
            "profile_details": {
                "allOf": [{
                    "$ref": "#/definitions/profile_list"
                }, {
                    "type": "object",
                    "properties": {
                        "first_name": {"type": "string"}
                    }
                }]
            },
            "profile_details_extended": {
                "allOf": [
                    {
                        "$ref": "#/definitions/profile_details"
                    }, {
                        "type": "object",
                        "properties": {
                            "last_name": {"type": "string"}
                        }
                    }
                ]
            },
            "profile_details_extended_again": {
                "allOf": [
                    {
                        "$ref": "#/definitions/profile_details_extended"
                    },
                    {
                        "type": "object",
                        "properties": {
                            "email": {"type": "string"}
                        }
                    }
                ]
            }
    }
    ...
    in paths:
    ...
            "post": {
                "operationId": "profiles_create",
                "responses": {
                    "201": {
                        "description": "test",
                        "schema": {
                            "$ref": "#/definitions/profile_details_extended_again"
                        }
                    }
                }

Swagger-UI configuration options:

SwaggerUIBundle({
        url: "schema.json",
        dom_id: '#swagger-ui',
        deepLinking: true,
        docExpansion: 'none',
        presets: [
          SwaggerUIBundle.presets.apis,
          SwaggerUIStandalonePreset
        ],
        plugins: [
          SwaggerUIBundle.plugins.DownloadUrl
        ],
        layout: "StandaloneLayout"
})

Describe the bug you're encountering

Schema displayed in swagger is not correct. Please see the screenshots

To reproduce...

Steps to reproduce the behavior:

1. Go to path definition and see the responses

Expected behavior

Correct schema should be used

Screenshots

Bugged response schema. Note that schema has no name and two fields are missing. It appears like instead of using profile_details_extended_again its using profile_details.

It should look like this:

This is screenshot of an example of endpoint that is using parent schema (profile_details_extended) and is rendered properly:

[hkosova]

Your example uses a mix of OpenAPI 3.0 and 2.0 syntax.

If you use "openapi": "3.0.0", as indicated by #/components/schemas, the response definition should look as follows, with the schema wrapped into content.application/json:

            "post": {
                "operationId": "profiles_create",
                "responses": {
                    "201": {
                        "description": "test",
                        "content": {
                            "application/json": {
                                "schema": {
                                    "$ref": "#/components/schemas/profile_details_extended_again"
                                }
                            }
                        }
                    }
                }
            }

If you use "swagger": "2.0", then the models should be defined in definitions, not in components/schemas, and the $refs should be changed appropriately.

You can paste your spec info Swagger Editor http://editor.swagger.io to verify the syntax.

Also, if your profile model is always an object, make sure to add "type": "object". The properties keyword alone is not enough. This post explains why.

[mlubimow]

@hkosova I've fixed all the issues with the schema, it validates in editor.swagger.io but I still have the same issue - the model for POST response is not picked up properly (although its visible in models section on the main page).

ps I've updated the original post with the current code.

[hkosova]

Please post your updated spec (e.g. as a gist).

[mlubimow]

@hkosova https://gist.github.com/mlubimow/82197b24aa3e07432b6d159642bc8077

[rmanoka]

+1. Have this issue on OAS 3.0.0 too when schema uses more than 2-levels of nested allOf

[DrFairy]

@hkosova Simplified reproduction of the same error (allOf of one object is to simplify the example, there are 2+ mixed objects there in a real use case):
https://gist.github.com/DrFairy/6ad4f8ccd8faedbf8c9725d4ccecd9da

Expected example value:
{ "p1": { "p2": {} } }

Actual value
{ "p1": {} }

Also, js error "TypeError: Cannot read property '0' of undefined" appears caused presumably here https://gist.github.com/DrFairy/6ad4f8ccd8faedbf8c9725d4ccecd9da#file-swagger-yml-L23

The problem is that in complex schemas nesting cases this bug RANDOMLY REMOVES some parts of entities and fixing it for one case can generate the same bug in other places.

[gergelypap]

+1

Can confirm this using OAS 3.0 specification. As a workaround, I copy-pasted my top parent allOf list to its children...

[tahoward]

I'm getting this as well and it appears to be an ordering issue in my particular case.

I played around with the online editor and identified that when my YAML definition gets converted to JSON specification (using connexion) the components attribute ends up being the first attribute in the spec coming before paths. In this configuration my nested schemas do not render properly (unless they are inside an array (weird)) . If I manually load a JSON specification where my ordering in the YAML is preserved (components defined AFTER paths) everything renders fine.

[gilad-bendor]

+1
Same problem... :-(

[jacobjmarks]

Encountered the same issue here. My model - which used allOf within a property of type array - was not being rendered when referenced in a Response in the same (correct) way it was being rendered as a standalone Schema.

Issues were resolved when I moved my component definition below my paths definition within my openapi: 3.0.0 JSON spec; as mentioned above by @tahoward (Thanks!).

[tim-lai]

fixed in [email protected]