[Bug]: Inconsistent examples/schemas generated for types

[danlyons-home]

Describe the bug

Body and response example and schema can be different despite an endpoint using the same type for both body and response.

Expected behavior

I would expect that for any type T that the example and schema representing said type should be identical in the body and response section of the generated swagger documentation.

Actual behavior

The schemas and examples for the type differ.

For example, when System.Drawing.Size is sent/received either directly or as a child of the type actually being sent/received, the generated example body is as follows:

{
  "width": 0,
  "height": 0
}

with schema

while the generated example response is as follows:

{
  "isEmpty": true,
  "width": 0,
  "height": 0
}

with schema

Steps to reproduce

Run dotnet new webapi -controllers.

Add the following to WeatherForecastController:

    public sealed record FooItem(int Id, Size size, string Name);

    [HttpPost("/size")]
    public Size ChangeSize([FromBody] Size newSize) => newSize;

    [HttpPost("/item")]
    public FooItem ChangeItem([FromBody] FooItem item) => item;

Start the project. The generated swagger doc page that comes up in the debug session will include the different body/response examples/schemas.

Exception(s) (if any)

No response

Swashbuckle.AspNetCore version

6.4.0, 6.6.2, 6.7.0

.NET Version

8.0.205

Anything else?

No response

[danlyons-home]

The Size example is rather trivial, in that the empty flag is vestigial data. However, in my production code, I have types where meaningful properties (e.g., even collections) may be excluded in some examples/schema. Size just happens to be a neat, trivial way to reproduce the issue.

What I've noticed is that the response example/schema appears to be the correct one whenever there is a disparity between body and response.

[jgarciadelanoceda]

The field IsEmpty is Read-Only, so the Swagger-Ui must be taking this field out of the Request, because if you put it it will be ignored.
The only thing that SB is doing here is putting the field as Read-Only which is correct, and because of this the Swagger-Ui is not showing it on the Request(Which for me makes sense), because if you send a request with the field set to whatever value it will be overriden
You could unmark is as RO, on a SchemaFilter(Doing this you will see this field in the request), but the behaviour here seems more than correct