OpenAPI documentation is incorrect when using custom TryParse() binding with Minimal APIs

[marcominerva]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have used the same title of #36412 because the same issue happens today using the new OpenAPI documentation generator that is built-in in .NET 9.0.

With this code:

app.MapGet("/student/{student}", (Student student) => $"Hi {student.Name}");

public record Student(string Name)
{
    public static bool TryParse(string value, out Student? result)
    {
        if (value is null)
        {
            result = null;
            return false;
        }

        result = new Student(value);
        return true;
    }
}

OpenAPI documentation is wrongly created as the following:

"parameters": [
    {
        "name": "student",
        "in": "query",
        "required": true,
        "schema": {
            "$ref": "#/components/schemas/Student"
        }
    }
],
// ...
"components": {
    "schemas": {
        "Student": {
            "required": [
                "name"
            ],
            "type": "object",
            "properties": {
                "name": {
                    "type": "string"
                }
            }
        }
    }
},

Expected Behavior

Parameters that use a TryParse custom binding should be configured as string in the openapi/v1.json file:

"parameters": [
    {
        "name": "student",
        "in": "query",
        "required": true,
        "schema": {
            "type": "string"
        }
    }
],

Steps To Reproduce

Minimal repro: https://github.com/marcominerva/TryParseOpenApiIssue

Exceptions (if any)

No response

.NET Version

9.0.0-rc.2.24474.3

Anything else?

No response

[captainsafia]

@marcominerva Thanks for filing this issue!

I believe that this was a regression that was introduced in the model binding layer in this commit although I'll have to debug a little further. I'm a little surprised that our AddsFromRouteParameterAsPathWithCustomClassWithTryParse test didn't catch this although the actual issue might be something else.

It seems like you also reproed this with .NET 9 and Swashbuckle? If so, that would point more towards it being an ApiExplorer problem as opposed to a something in the M.A.OpenApi package. I'll try to take a further look at this.

[marcominerva]

Yes @captainsafia, it seems that the issue happens also with the latest version of Swashbuckle.AspNetCore: domaindrivendev/Swashbuckle.AspNetCore#3105.

Thank you for your support!

[marcominerva]

@captainsafia I noticed that the issue is solved only if I don't use .Accepts<T>:

// Will correcly report a student as a query string parameter
app.MapPost("/enroll", (Student student) => Results.NoContent());

// Will report a student as a query string parameter and as the request body
app.MapPost("/enroll-withaccepts", (Student student) => Results.NoContent())
   .Accepts<Student>("application/json");

// Will correctly report the parameter as a string
app.MapGet("/student/{student}", (Student student) => $"Hi {student.Name}");

// Will correctly report the parameter as a string and a the request body
app.MapGet("/student-withaccepts/{student}", (Student student) => $"Hi {student.Name}")
    .Accepts<Student>("application/json");

app.Run();

public record Student(string Name)
{
    public static bool TryParse(string value, out Student? result)
    {
        if (value is null)
        {
            result = null;
            return false;
        }

        result = new Student(value);
        return true;
    }
}

For example:

I have updated the repo at https://github.com/marcominerva/TryParseOpenApiIssue with this new scenarios.