Inconsistent OpenAPI responses with TypedResults / minimal API

[CaringDev]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Generated responses (status codes) in OpenAPI documents are inconsistent when returning a result TResult, that result as part of Results<TResults, NotFound> or Results<TResults, NotFound, Ok>.

Expected Behavior

all the following methods should include a 200 response:

FileStreamHttpResult Get(...)
Results<FileStreamHttpResult, NotFound> Get(...)
Results<FileStreamHttpResult, NotFound, Ok> Get(...)

The latter being our current workaround.

Steps To Reproduce

dotnet new webapi
dotnet package add Microsoft.Extensions.ApiDescription.Server

add the following before app.Run()

app.MapGet("/ok200", () => TypedResults.File([]));
app.MapGet("/NOK/", new Func<Results<FileContentHttpResult, NotFound>>(() => TypedResults.File([])));
app.MapGet("/okok/", new Func<Results<FileContentHttpResult, NotFound, Ok>>(() => TypedResults.NotFound()));

Exceptions (if any)

No response

.NET Version

10.0.300

Anything else?

related: #65371

[github-actions]

Triage Summary

Area: area-minimal — The issue is about OpenAPI document generation for minimal API endpoints using TypedResults and Results<T1, T2>. The inconsistency appears in response status code generation for FileStreamHttpResult when wrapped in Results<...> union types.

Type: Bug — Specific, reproducible behavior where the generated OpenAPI responses are incorrect/incomplete depending on the return type form used.

Regression Info

(No regression information provided — no prior working version mentioned.)

Potential Duplicates

• ApiExplorer doesn't propagate non-success Results types #65371 - "ApiExplorer doesn't propagate non-success Results types" (similarity: medium — related root cause around Results<T...> type propagation in OpenAPI/ApiExplorer, but that issue focuses on MVC controllers and non-success types, while this one targets minimal APIs and the success FileStreamHttpResult type)

Notes

• The reporter explicitly references ApiExplorer doesn't propagate non-success Results types #65371 as related.
• The workaround mentioned (Results<FileStreamHttpResult, NotFound, Ok>) suggests the issue may be in how the OpenAPI schema generator resolves types from Results<T1, T2> unions for file results specifically.
• May warrant investigating whether FileStreamHttpResult has special-cased handling that differs from other IResult types in the response metadata resolution path.

Generated by Issue Triage Agent for dotnet/aspnetcore for issue #66890 · sonnet46 616.1K · ◷

[CaringDev]

Seems this is fixed in .NET 11: https://learn.microsoft.com/en-us/aspnet/core/release-notes/aspnetcore-11?tabs=minimal-apis#file-stream-result-types-appear-in-openapi-documents
Will check...