Extend ModelError class with the ability to have custom validation properties and values

[kzaabox]

Related item:

Improve validation for non-interactive consumption

Problem:

Currently it is not possible to attach custom properties to the model validation result object.
The ModelError class can only store a message (ErrorMessage property) for a validation error.
In most cases it is not enough because at least an ErrorCode should also be attached to it.

A possible solution:

By adding for example an IDictionary<string, object> ErrorDetails {get; set;} property to the ModelError class would enable the validation attributes to add additional data to a validation result.
The keys could be the names of the added properties.
It would also be great because with such an extended ModelError class, 3rd party model validators (e.g.: FluentValidation) could attach their validation properties to it.
See ValidationFailure class of FluentValidator.
It contains properties like CustomState, and ErrorCode which will be lost when someone using this library with the built-in validation logic of ASP.NET Core, because there is no place for those properties in the ModelError class.
Of course any other solution could work as long as it would be backward compatible with the current implementation.

Workaround:

In order to have the complete validation result of the FluentValidation.AspNetCore package, I wrote an ActionFilter and I attached it to every action methods for every controllers.
The input model validation is done manually in this filter by using FluentValidation and if there was any validation error, the request is short-circuited by setting the response object (an extended version of the ValidationProblemDetails).
With this method however I had to opt-out from the goodness of the new ControllerBase class (automatic BadRequest reponse on ModelState.IsValid == false) by setting the SuppressModelStateInvalidFilter property of the ApiBehaviorOptions in the ConfigureServices method of the startup code of the service.

Additionally the ValidationProblemDetails class also lack of the ability to have custom KV pairs for validation results.
So by extending the ModelError class would mean that the ValidationProblemDetails class should also be extended in order to have a response body at the end of the pipeline which would contain every additional validation properties and their values too.

[mkArtakMSFT]

We've moved this issue to the Backlog milestone. This means that it is not going to happen for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[EricStG]

This would be useful in cases when we want to provide both a human and a machine readable error. The only way to do this now, as far as I'm aware, is by mostly ignoring ValidationProblemDetails in favour or a custom model