Skip to content
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

Closed
fpintos opened this issue May 1, 2018 · 6 comments
Labels
Milestone

Comments

@fpintos
Copy link

fpintos commented May 1, 2018

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.

@xuzhg xuzhg added the P4 label May 8, 2018
@AlanWong-MS AlanWong-MS added this to the v7.0 milestone May 30, 2018
@madansr7 madansr7 modified the milestones: v7.0, vNext Jun 13, 2018
@swhillance-mphn
Copy link

This issue is causing massive headaches for our team

@fpintos
Copy link
Author

fpintos commented Aug 31, 2018

If it helps anyone else out there, I've worked around this issue by creating a custom JSON reader.
See this GIST for a JSON reader that reports all property names in lower-camel-case.

@brjohnstmsft
Copy link
Contributor

@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).

brjohnstmsft added a commit to brjohnstmsft/WebApi that referenced this issue Sep 23, 2018
This is addresses the unhelpful error message described in this GitHub issue:

OData#1421
@fpintos
Copy link
Author

fpintos commented Sep 23, 2018

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.

@AlanWong-MS AlanWong-MS added P2 and removed P4 labels Sep 24, 2018
@brjohnstmsft
Copy link
Contributor

@xuzhg @AlanWong-MS I think you guys can close this issue now that the PR has been merged.

@biaol-odata
Copy link
Contributor

Closed as merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants