v2.8.14 ignoring @Schema annotation

[cavazos-apps]

Describe the bug After updating from v2.8.13 to 2.8.14, the @Schema annotation appears to be ignored. Specifically, @Schema(description = "field", type = "integer", example = "22") is being displayed as:

"field": {
            "type": "string",
            "description": "field",
            "example": "22"
          }

where the previous version would show:

"field": {
            "type": "integer",
            "description": "field",
            "example": "22"
          }

To Reproduce Steps to reproduce the behavior: Set schema explicitly using @Schema annotation, check /v3/api-docs and see mismatch.

• What version of spring-boot you are using? 3.5.8
• What modules and versions of springdoc-openapi are you using? org.springdoc:springdoc-openapi-starter-webmvc-ui:2.8.14
• What is the actual and the expected result using OpenAPI Description (yml or json)? Actual:

"field": {
            "type": "string",
            "description": "field",
            "example": "22"
          }

Expected:

"field": {
            "type": "integer",
            "description": "field",
            "example": "22"
          }

• Provide with a sample code (HelloController) or Test that reproduces the problem

@RestController
public class HelloController {

    @GetMapping("/hello")
    public SampleResponse hello() {
        SampleResponse res = new SampleResponse();
        res.setField(true);
        res.setCount(22);
        res.setNote("ok");
        return res;
    }

    public static class SampleResponse {

        // Explicit override (expected: boolean), but in 2.8.14 becomes string in /v3/api-docs
        @Schema(description = "field", type = "boolean", example = "true")
        private Boolean field;

        // Control case: explicit integer (expected integer)
        @Schema(description = "count", type = "integer", example = "22")
        private Integer count;

        // Control case: inferred string (expected string)
        private String note;

        public Boolean getField() { return field; }
        public void setField(Boolean field) { this.field = field; }

        public Integer getCount() { return count; }
        public void setCount(Integer count) { this.count = count; }

        public String getNote() { return note; }
        public void setNote(String note) { this.note = note; }
    }
}

Expected behavior Correctly set the type according to the explicit @Schema annotation

[cavazos-apps]

[Mattias-Sehlstedt]

Most likely tied to the bump of swagger-core here. It is the component responsible for most of the Java-object to OpenApi-specification translation.

Could you state if you are exposing a 3.1 or 3.0 specification? If it is 3.1, I believe the correct field to use is types, so you could try to see if that adjusts the behavior.

[cavazos-apps]

Most likely tied to the bump of swagger-core here. It is the component responsible for most of the Java-object to OpenApi-specification translation.

Could you state if you are exposing a 3.1 or 3.0 specification? If it is 3.1, I believe the correct field to use is types, so you could try to see if that adjusts the behavior.

I can verify it is a 3.0 specification. I understand it is not recommended to specify the version but a consuming client is currently reliant on that 3.0.

[Mattias-Sehlstedt]

My attempt at reproducing the issue does not seem to yield the same results. Could you submit an example branch where you are able to reproduce the issue in this repository?

[cavazos-apps]

https://github.com/cavazos-apps/springdoc-test

here is the test where I was able to recreate it.

[Mattias-Sehlstedt]

https://github.com/cavazos-apps/springdoc-test

This application exposes a 3.1 specification.

I have verified that it is specifically tied to it being a 3.1 specification. See the attempt again. I have also verified that changing to types resolves the issue for the boolean casting (number and integer from my examples were not resolved by it).

But I would say that this confirms that the issue lies within swagger-core, and thus the issue should be raised and investigated there (it might for example be that one of the newer versions has already resolves it).

[cavazos-apps]

Sounds good, appreciate you looking into it.

[Mattias-Sehlstedt]

I took part in bumping the version, and I saw some indications of a change in behavior.

But provided the changes made between 36 and 38, I do not really see what should cause it. https://github.com/swagger-api/swagger-core/compare/v2.2.36...v2.2.38, summarized with:

[cavazos-apps]

I have verified that it is specifically tied to it being a 3.1 specification.

I did alter the example to expose a 3.0.3 specification and the result is the same via:

@Bean
    public OpenApiCustomizer openApiCustomizer() {
        return openApi -> openApi.setOpenapi("3.0.3");
    }

[cavazos-apps]

I have verified that it is specifically tied to it being a 3.1 specification.

I did alter the example to expose a 3.0.3 specification and the result is the same via:

@Bean
    public OpenApiCustomizer openApiCustomizer() {
        return openApi -> openApi.setOpenapi("3.0.3");
    }

Nevermind, I see the property springdoc.api-docs.version=openapi_3_0 to properly change the version and see it is only an issue with openapi_3_1.