.NET 7 Preview 7 ProblemDetailsService is not working as expected.

[TanvirArjel]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The release note says that:

.NET 7 Preview 7 introduces a new problem details service based on the IProblemDetailsService interface for generating consistent problem details responses in your app.

To add the problem details service, use the AddProblemDetails extension method on IServiceCollection.

builder.Services.AddProblemDetails();

I have done so. Now I have the following endpoint:

[HttpPost]
public ActionResult Post(CreateWFModel model)
{
    if (model.Summary?.Length < 100)
    {
        ModelState.AddModelError("Summary", "The summary should be at least 100 characters.");
        return BadRequest(ModelState);
    }

    return Ok();
}

public class CreateWFModel
{
    public DateTime Date { get; set; }

    public int TemperatureC { get; set; }

    [Required]
    public string? Summary { get; set; }
}

Now if I don't provide the value of the summary then the response shows as follows:

{
  "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "traceId": "00-2759a2ba3ce779e64e8ec4f21e4565fc-7b9e6059c062c576-00",
  "errors": {
    "Summary": [
      "The Summary field is required."
    ]
  }
}

This is fine!

But when I provide less than 100 chars, the response shows as follows:

{
  "Summary": [
    "The summary should be at least 100 characters."
  ]
}

Which is totally inconsistent. I want the response should be:

{
  "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "traceId": "00-2759a2ba3ce779e64e8ec4f21e4565fc-7b9e6059c062c576-00",
  "errors": {
    "Summary": [
       "The summary should be at least 100 characters."
    ]
  }
}

I have also tried the following but the result is the same:

public class CustomWriter : IProblemDetailsWriter
{
    // Indicates that only responses with StatusCode == 400
    // will be handled by this writer. All others will be
    // handled by different registered writers if available.
    public bool CanWrite(ProblemDetailsContext context) 
        => context.HttpContext.Response.StatusCode == 400;

    public ValueTask WriteAsync(ProblemDetailsContext context)
    {
        //Additional customizations

        // Write to the response
        context.HttpContext.Response.WriteAsJsonAsync(context.ProblemDetails);
       return ValueTask.CompletedTask;
    }        
}

builder.Services.AddSingleton<IProblemDetailsWriter, CustomWriter>();
builder.Services.AddProblemDetails();

.NET Version

.NET 7.0 Preview 7

[davidfowl]

cc @brunolins16

[brunolins16]

@TanvirArjel I have very happy that you have tried the new ProblemDetailsService 😁.

If you take a look at the same release notes (Diagnostics middleware updates) we mentioned about updates in the middleware to make the response consistent and there we have mentioned a key important aspect of this change.

The following sample configures the app to generate a problem details response for all HTTP client and server error responses that do not have a body content yet.

Basically, it means that once you have a body defined the middleware will not call the problem details service to generate a Problem Details payload. It is similar to what you have in your scenario, but in your case the MVC engine is responsible to autogenerate the payload when the body is empty.

In your code return BadRequest(ModelState); call will serialize the ModelStateDictionary to the body avoid the Problem Details autogeneration.

[TanvirArjel]

In your code return BadRequest(ModelState); call will serialize the ModelStateDictionary to the body avoid the Problem Details autogeneration.

Yes! That's why this behavior is inconsistent and error-prone and the response for the bad requests always should be the same.

[brunolins16]

With all that said, that is the current expected behavior. However, I can understand your expectation once the service is registered and I think since now we have a service that allow a consistent generation might be an interesting change to generate PD in these scenarios as well,

[TanvirArjel]

@brunolins16

I think since now we have a service that allows a consistent generation might be an interesting change to generate PD in these scenarios as well,

Yes! otherwise, the Client App calling the ASP.NET Core API will be broken while handling the bad request error response.

[brunolins16]

In your code return BadRequest(ModelState); call will serialize the ModelStateDictionary to the body avoid the Problem Details autogeneration.

Yes! That's why this behavior is inconsistent and error-prone and the response for the bad requests always should be the same.

Totally agree! I think we have commented at same time. In my opinion, adding the new service was a start point to make the Problem Details generation consistent, but we still need to make additional changes to allow it to be customizable and consistent in scenarios as you mentioned.

[brunolins16]

For now, to make it consistent I recommend you keep using return ValidationProblem(ModelState);

[TanvirArjel]

@brunolins16 This is a very crucial bug. I am surprised that this very basic requirement is not noticed by ASP.NET Core Team while they are going to release version 7.0 soon.

[TanvirArjel]

@brunolins16

For now, to make it consistent I recommend you keep using return ValidationProblem(ModelState);

Thanks! I am aware of this.

[brunolins16]

@brunolins16

For now, to make it consistent I recommend you keep using return ValidationProblem(ModelState);

Thanks! I am aware of this. But writing it everywhere will be ugly.

I understand you, but I don't see, in your specific example, how uglier it is since it is basically a validation problem already,

@brunolins16 This is a very crucial bug. I am surprised that this very basic requirement is not noticed by ASP.NET Core Team while they are going to release version 7.0 soon.

I was the team member who worked on this and to be honest probably I missed because the main scenario was the auto generation (when a body was not defined already) that we used to have no control and, in your case, you do have control what you want to generate (calling ValidationProblem/ Problem/etc...), and this current behavior is very well documented

Unfortunately, we are very late in .NET 7 development and might not be possible to have it done :(

[TanvirArjel]

@brunolins16 Wish you all the very best for dotNET 8.0 :) But please don't miss this.