Discussed with Youssef that ODataError right now doesn't support custom error, so we will lose the modelstate's errors in odata error message.
However, ModelState errors are very common in real application to help caller to identify what's wrong with his parameter. We'd better to support it, otherwise user has to parse the modelstate by themselves to convert to ODataError.
Comments: Is there an update or other news related to modelstate errors received from an OData service? Personally, I only wish that the error messages could be more easily parsed as a JSON result containing key/value pairs. Currently if we implement `ValidationActionFilter` utilizing `DataHttpRequestMessageExtensions::CreateErrorResponse` passing a `ModelStateDictionary` the model state dictionary gets flattened out into a non-JSON string representation of errors and encoded into the ```innererror::message``` value: ``` { "odata.error":{ "code":"","message":{ "lang":"en-US","value":"The request is invalid." },"innererror":{ "message":"entity.Name : The Name field is required.\r\n","type":"","stacktrace":"" // <-- ewww } } } ``` The overall payload format is acceptable, but as you can see there is no way to interpret 'message' as anything other than a string. I could post-process the result (including scrubbing key names to drop any meaningless prefix such as 'entity'), but who knows how long before the format changes and I need to go back and re-parse (or completely rewrite) dependent code. Additionally, and a bit off-topic, it's impossible to know with certainty that I should even be interpreting the error response for modelstate errors. There is no code specified, and all messages are nonspecific (see above snippet, lack of any meaningful 'Code'.) Now.. there is the following method: ``` internal static HttpResponseMessage CreateErrorResponse(this HttpRequestMessage request, HttpStatusCode statusCode, string message, string messageDetail) ``` In the interim I will likely leverage the above, using a bit of reflection to invoke it despite it being marked 'internal', as it will let me emit an error detail in the format I can more easily parse on the client-side. __I only bring this up since, if not marked internal, it would provide us with an extensibility point that seems acceptable. I can create an Error Response with any message+detail my client code would require.__ Perhaps I'm uninformed, and there's a good reason for this method being marked internal? Further, it seems the limitation here isn't with ODataError, per-se, but with the extension methods in System.Web.Http.OData.. For example, ODataHttpErrorExtensions has a method ```ConvertModelStateErrors(HttpError error)``` which is used to translate ```ModelStateDictionary``` into a string. This code has discrete knowledge of "ModelState" but makes no attempt to convert it into a format that can be easily reversed into its original structure (basically, this is where structural value of modelstatedictionary is lost, and it does this for any key/value collection not just modelstatedictionary.) --- All else aside, I believe ```ConvertModelStateErrors``` needs to be refactored to provide a JSON-friendly string if/while ODataError is unable to represent as anything other than a string, Fx, sth like this could be interpreted by a JSON-capable client: ``` { "odata.error":{ "code":"","message":{ "lang":"en-US","value":"The request is invalid." },"innererror":{ "message":"'Name' : 'The Name field is required.', 'Foo' : 'The Foo field is required.',","type":"","stacktrace":"" } } } ``` Hopefully this isn't one of those cases where I should have pulled the latest nightly (I'm still working against the 1/18 nightly.) As usual, thanks for any info/assists! :)
However, ModelState errors are very common in real application to help caller to identify what's wrong with his parameter. We'd better to support it, otherwise user has to parse the modelstate by themselves to convert to ODataError.
Comments: Is there an update or other news related to modelstate errors received from an OData service? Personally, I only wish that the error messages could be more easily parsed as a JSON result containing key/value pairs. Currently if we implement `ValidationActionFilter` utilizing `DataHttpRequestMessageExtensions::CreateErrorResponse` passing a `ModelStateDictionary` the model state dictionary gets flattened out into a non-JSON string representation of errors and encoded into the ```innererror::message``` value: ``` { "odata.error":{ "code":"","message":{ "lang":"en-US","value":"The request is invalid." },"innererror":{ "message":"entity.Name : The Name field is required.\r\n","type":"","stacktrace":"" // <-- ewww } } } ``` The overall payload format is acceptable, but as you can see there is no way to interpret 'message' as anything other than a string. I could post-process the result (including scrubbing key names to drop any meaningless prefix such as 'entity'), but who knows how long before the format changes and I need to go back and re-parse (or completely rewrite) dependent code. Additionally, and a bit off-topic, it's impossible to know with certainty that I should even be interpreting the error response for modelstate errors. There is no code specified, and all messages are nonspecific (see above snippet, lack of any meaningful 'Code'.) Now.. there is the following method: ``` internal static HttpResponseMessage CreateErrorResponse(this HttpRequestMessage request, HttpStatusCode statusCode, string message, string messageDetail) ``` In the interim I will likely leverage the above, using a bit of reflection to invoke it despite it being marked 'internal', as it will let me emit an error detail in the format I can more easily parse on the client-side. __I only bring this up since, if not marked internal, it would provide us with an extensibility point that seems acceptable. I can create an Error Response with any message+detail my client code would require.__ Perhaps I'm uninformed, and there's a good reason for this method being marked internal? Further, it seems the limitation here isn't with ODataError, per-se, but with the extension methods in System.Web.Http.OData.. For example, ODataHttpErrorExtensions has a method ```ConvertModelStateErrors(HttpError error)``` which is used to translate ```ModelStateDictionary``` into a string. This code has discrete knowledge of "ModelState" but makes no attempt to convert it into a format that can be easily reversed into its original structure (basically, this is where structural value of modelstatedictionary is lost, and it does this for any key/value collection not just modelstatedictionary.) --- All else aside, I believe ```ConvertModelStateErrors``` needs to be refactored to provide a JSON-friendly string if/while ODataError is unable to represent as anything other than a string, Fx, sth like this could be interpreted by a JSON-capable client: ``` { "odata.error":{ "code":"","message":{ "lang":"en-US","value":"The request is invalid." },"innererror":{ "message":"'Name' : 'The Name field is required.', 'Foo' : 'The Foo field is required.',","type":"","stacktrace":"" } } } ``` Hopefully this isn't one of those cases where I should have pulled the latest nightly (I'm still working against the 1/18 nightly.) As usual, thanks for any info/assists! :)