New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Does not support untyped value in non-open type." when structured type is received and properties are in incorrect case #1421
Comments
This issue is causing massive headaches for our team |
If it helps anyone else out there, I've worked around this issue by creating a custom JSON reader. |
@fpintos Did you file this issue because you think properties that differ only by case should be recognized, or because the error message is unhelpful? The OData spec seems to indicate that case-sensitivity is the expected behavior (maybe @mikepizzo can confirm?). That's not to say that the OData team won't ever implement that feature; I am not on that team and don't speak for them. I just want to clarify what the proposed fix is. My team (Azure Search) is in the midst of upgrading from Web API OData 5.9 to 7.0.1, and we ran across this issue too. For us, the regression of the error message is particularly bad because our customers often see this error message when working with the wrong version of their schema (i.e. -- they send properties that exist on a different version of the schema than the one they're interacting with). I've created a repro to show the change in error message here: https://github.com/brjohnstmsft/odata-repros/tree/master/UnknownFieldErrorMessage It seems that improving the error message is not that big of a change, so I'm working on a PR for that right now. My plan is to make the error message identical to the one returned by the old version of ODataLib (6.19 and earlier). |
This is addresses the unhelpful error message described in this GitHub issue: OData#1421
A better message is sufficient. I have a workaround (see my previous comment) to deal with the case differences between the internal workloads used by Graph that prompted me into this path. |
@xuzhg @AlanWong-MS I think you guys can close this issue now that the PR has been merged. |
Closed as merged. |
When I receive a JSON object representing a structured type in the payload and the property names have incorrect case, I get back an ODataException with the message "Does not support untyped value in non-open type."
The error does not provide a good indication of which type/property is a cause of the error.
Assemblies affected
System.Web.OData 6.01.0.10907
Reproduce steps
Send a POST to an entity set and pass a property with incorrect case.
Expected result
Either a better error message, indicating which property is at fault or for property names to be case insensitive.
Actual result
In DeserializationHelpers.ApplyProperty we receive an ODataProperty but we fail to find its edmProperty. If the structured type is not open, we get the error mentioned above. The client is left to wonder which property is causing trouble.
Additional detail
I found this issue while trying to integrate a workload into MSGraph and sharing a type with Exchange.
In my schema the types were copied from Graph and have lowercase properties, but in Exchange (which is the source of the particular complex type) the properties are camel case.
When sending a request directly to my workload with lowercase properties, things work as expected.
When testing via Graph with just my workload in a test schema, things also worked.
But once I tried to test in Graph with Exchange in the schema, then the issue surfaced, because Graph changed the case of the properties in the payload and then my workload refuses them.
The text was updated successfully, but these errors were encountered: