ProducesResponseType(typeof(void), ...) causes ApiExplorer to indicate the return type is ProblemDetails

[kingmotley]

Describe the bug

ApiExplorer/ProducesResponseType exposes incorrect value when the return type is void. It seems to override any attempt to indicate that the response produces no results/body with ProblemDetails.

To Reproduce

Steps to reproduce the behavior:

1. Using this version of ASP.NET Core 2.2
2. Apply the following attribute to an ApiController:
   [ProducesResponseType(typeof(void), (int)HttpStatusCode.Unauthorized)
3. ApiExplorer indicates the return type is ProblemDetails.

Expected behavior

ApiExplorer should say the return type is void.

[kingmotley]

Originally reported to Swashbuckle team here: domaindrivendev/Swashbuckle.AspNetCore#1043

[pranavkm]

I'm marking this as a bug to see if there's interest in making this work out of the box. For 2.2, you could do this by specifying a ProducesErrorResponseAttribute e.g.

[ProducesErrorResponseType(typeof(void)]
[ProducesResponseType(StatusCodes.Unauthorized)]
public IActionResult Method() => {}

That said, do you actually see an empty body in the response? ApiController adds a result filter by default that should turn your 401 unauthorized status code result to one with a ProblemDetails body.

[kingmotley]

Sorry, was away for a week. Yes, the actual body is empty on a 401, which is what I would expect (probably). Swagger shows that it returns a ProblemDetails, but it does not in actual use.

Adding [ProducesErrorResponseType(typeof(void))] does appear to change the 401 to a void in swagger.

[danroth27]

@pranavkm Is there anything actionable here then?

[LiangZugeng]

We are using NSwag to produce TypeScript client classes and we encountered this issue, to summarize:

1. [ProducesErrorResponseType(typeof(void))] works expectedly
2. [ProducesResponseType(typeof(void), StatusCodes.Status401Unauthorized)] produces ProblemDetails type for 401 status code.

May we know the status of this fix? Will it be released in v3.1 or in v5.0?

[icnocop]

I found a work-around here: domaindrivendev/Swashbuckle.AspNetCore#1752 (comment)