ModelState errors reported by Microsoft.AspNetCore.Mvc.NewtonsoftJson

[wiesniak]

Describe the bug

Problem is related to the migration from ASP.NET MVC (.NET Framework 4.8) web application to .NET 5 and is about different amount of errors when parsing wrong JSON request.

In old code we had some JsonFormatter configuration

public void RegisterConfiguration(HttpConfiguration config, IDependenciesResolver resolver)
{
    // ... exact settings don't matter here - just an example
    config.Formatters.JsonFormatter.SerializerSettings = new JsonSerializerSettings
        { NullValueHandling = NullValueHandling.Ignore };
    config.Formatters.JsonFormatter.SerializerSettings.Converters.Add(new StringEnumConverter());
    // ...

We have migrated the app and moved to Microsoft.AspNetCore.Mvc.NewtonsoftJson so our settings changed to

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers(options =>
    {
        // ...
    })
    .AddNewtonsoftJson(options =>
    {
        // example setting - for the sake of issue there can be no options set
        options.AllowInputFormatterExceptionMessages = false;
    });

We have some API POST endpoint that consumes some data model parsed from json, example:

{
  "surpriseTime": "2021-06-10T22:34:51.702Z",
  "details": {
    "candyCount": abc
  }
}

As you can notice, for "candyCount" there is an incorrect value assigned.
For old app we received error message

[
  {
    "Message": "Unexpected character encountered while parsing value: a. Path 'Details.CandyCount', line 4, position 19.",
    "Property": "surpriseModel.Details.CandyCount"  // this is a Key of ModelState KeyValuePair entry.
  }
]

In migrated app we get two errors

[
  {
    "message": "Unexpected character encountered while parsing value: a. Path 'details.candyCount', line 4, position 19.",
    "property": "details.candyCount"
  },
  {
    "message": "Unexpected character encountered while parsing value: b. Path 'details.candyCount', line 4, position 19.",
    "property": "details.candyCount.details"
  }
]

If I get rid of AddNewtonsoftJson call, there is one message again.

I have checked the behavior of Newtonsoft.Json for both frameworks by attaching to SerializerSettings.Error delegate and in both cases the same amount of calls is done - it is 3 for such json as above.
If I nest some objects then the number of errors grows by 1 for each level.
There is also some weird property path generated for the errors. While first one does make sense, second one does not as there is no "details" property in type behind the "candyCount" (it is int). Type of the property does not matter - for DateTime that I tested error messages were the same.

I'm not sure if this is more a bug or a feature - Microsoft.AspNetCore.Mvc.NewtonsoftJson is more exact about number of errors coming from Newtonsoft.Json. On the other hand it does not make to much sense for me to have same multiple errors for one field. There is also the topic of weird key for ModelState entries.

To Reproduce

Sample code is provided here https://github.com/wiesniak/NewtonsoftJsonIssue
There are two similar projects, one for .NET 5 and one for .NET Framework 4.8.
When run, swagger should load with one endpoint. Put the json payload as mentioned above and execute the call. Response should contain errors as described.
Now about the code. There is a class ModelStateValidationAttribute (one for each project) that is a global action filter with OnActionExecuting method override. If you put a breakpoint there and investigate the actionContext.ModelState you'll see the amount of errors and should notice the difference between projects.

Further technical details

dotnet --info

.NET SDK (reflecting any global.json):
 Version:   5.0.203
 Commit:    383637d63f

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19042
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.203\

Host (useful for support):
  Version: 5.0.6
  Commit:  478b2f8c0e

.NET SDKs installed:
  2.1.524 [C:\Program Files\dotnet\sdk]
  3.1.409 [C:\Program Files\dotnet\sdk]
  5.0.104 [C:\Program Files\dotnet\sdk]
  5.0.203 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.27 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.27 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.27 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Code was executed via Visual Studio 2019 (16.9.6) but was also observed when app was deployed on Azure Web App.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.