Serialization error after upgrade to v5.0.0

So I have this code in my Startup.cs:

services.AddProblemDetails(setup =>
 {
    setup.IncludeExceptionDetails = (c, e) => environment.IsDevelopment(); // -> before updating to v5, I had _ =>environment.IsDevelopment(); here
    setup.Map<DomainValidationException>(
        (context, ex) => new ValidationProblemDetails(ex.Errors).Build(context));
});

Now my json looks like this, which blows up in deserialisation because of the duplicate “errors” field:

  {
    "errors": {
        "exportPath": [
            "..."
        ]
    },
    "type": "https://httpstatuses.com/400",
    "title": "One or more validation errors occurred.",
    "status": 400,
    "detail": "Please refer to the errors property for additional details.",
    "instance": "/api/externalApplications/4240656a-a669-4fba-842a-abbb00dca30f",
    "errors": [
        {
            "message": "Domain validation failed. See Errors for details.",
[...]

Before the update (v4.5), the json was just

{
    "errors": {
        "exportPath": [
            "..."
        ]
    },
    "type": "https://httpstatuses.com/400",
    "title": "One or more validation errors occurred.",
    "status": 400,
    "detail": "Please refer to the errors property for additional details.",
    "instance": "/api/externalApplications/7a52e19a-ce16-480c-9999-abbb00e0c8c7"
}

Fixed it by doing this in my startup, but I don’t know if this is what you intended:

setup.IncludeExceptionDetails = (c, e) =>
{
     return e switch
     {
         DomainValidationException _ => false,
         _ => environment.IsDevelopment()
    };
};

[angularsen]

@khellang I was just hit by this too, 1 year later on 5.4 after upgrading from 4.5. I second the ☝️ suggestion of changing the default name to exceptionDetails.

Out of the box, we run into problems with Refit no longer recognizing the validation error and throws Refit.ApiException instead of Refit.ValidationApiException, which loses the ProblemDetails it tries to deserialize for 400 Bad Request. Changing the property name fixed this.

Update: Created PR #139 .

[khellang]

Just pushed v5.1.0 to NuGet. It has an additional ExceptionDetailsPropertyName option that should let you use a different name 😄