Swashbuckle output different from demo

Dear Kristian,

I’ve noticed that in the demo at https://problem-details-demo.azurewebsites.net/swagger/index.html#/ApiMvc/ApiMvc_ErrorDetails the error has a description:

However, if I create a new ASP.Net 5.0 Web API, then I don’t get that description:

Everything else is the same as you can see. I’ve looked to the example source code, but couldn’t figure out what causes this. Do you have any idea?

The steps to reproduce: Create a new Web API in Visual Studio 2019, version 16.10.0 Preview 1.0 Add services.AddProblemDetails(ConfigureProblemDetails); to Startup.ConfigureServices(...) Add the following method to Startup:

private void ConfigureProblemDetails(ProblemDetailsOptions o)
{
    o.ValidationProblemStatusCode = StatusCodes.Status400BadRequest;
}

Add app.UseProblemDetails(); as first line to Startup.Configure(...)

Change the Get method in the WeaterForecastController to

[HttpGet]
[ProducesResponseType(StatusCodes.Status422UnprocessableEntity)]
public IEnumerable<WeatherForecast> Get()
{
   ModelState.AddModelError("someProperty", "This property failed validation.");

   var validation = new ValidationProblemDetails(ModelState)
   {
      Status = StatusCodes.Status422UnprocessableEntity
   };

   throw new ProblemDetailsException(validation);
}

[khellang]

It does three things:

1. It swaps MVC’s built-in ProblemDetailsFactory to use the middleware’s configuration instead. This will give you more consistent errors, no matter where they are produced. I.e. from MVC’s invalid state filter etc.
2. It turns off MVC’s built-in client error mapping, which also gives you more consistent error responses
3. It tries to set the produced error response type on API controllers, but apparently that isn’t working too well 😅

[khellang]

Oh, and it adds a filter that makes returning pre-baked ProblemDetails instances from controllers a bit more consistent, by calling the middleware hooks 😃

Sorry for being slow, but when exactly does nr 1 and 2 occur? I have no idea when invalid state filter or built-in client error mapping is used.

See the documentation here. Basically if you have an API controller that returns back a 4xx status code (with no body) or model validation fails, MVC will use the ProblemDetailsFactory to create an instance of ProblemDetails and return it back, bypassing this middleware completely. So in order to make the responses consistent between MVC and the middleware, I’ve provided the AddProblemDetailsConventions method to smooth things out a bit 😃