error rendering request parameter object in large service

[tomaskodaj]

I you have complex objects in request parameters (e.g. query parameter) referenced as "$ref", only first 11 "paths" are rendered correctly as "textarea", rest of them wont be rendered with example, and wont render textarea when you hit "try it out".

This bug was introduced in version 2.4.0... version 2.3.0 was OK.

Using with spring boot 3.2.3.

    "paths": {
...
                "parameters": [
                    {
                        "required": true,
                        "examples": {
                            "exampleFullSomeComplexObjectSchema": {
                                "$ref": "#/components/examples/exampleFullSomeComplexObjectSchema"
                            },
                            "exampleMinimalSomeComplexObjectSchema": {
                                "$ref": "#/components/examples/exampleMinimalSomeComplexObjectSchema"
                            }
                        },
                        "schema": {
                            "$ref": "#/components/schemas/SomeComplexObjectSchema"
                        },
                        "description": "Some Complex Object Schema",
                        "in": "query",
                        "name": "someComplexObjectSchema"
                    }

[codespearhead]

We need an MRE, like this one.

[tomaskodaj]

minimal example: bug-example.zip

see last approx 40 items and their request parameter "is". compare to first ~60 items. then recompile with 2.3.0 and it is correct. with 2.4.0 it is not. (be aware of browser cache when changing version - it might confuse you :))

[tomaskodaj]

Error is in swagger-ui.version = 5.11.8

Please upgrade to 5.11.10, where it seems fixed

(Bit unfortunate, that I need to define property springdoc.swagger-ui.version when I change dependency version on pom.xml, but I guess there is no other way, since webjars package contains files in folder with version name inside jar archive 😢)

[chaouki-reply]

We have faced the same behavior but hopefully, this will be fixed when merging PR#2542.