-
Notifications
You must be signed in to change notification settings - Fork 134
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
Trying to parse non-json responses - 'U' is an invalid start of a value. LineNumber: 0 #554
Comments
Could you please provide a link to specification describing that response format? |
Well, even the docs linked in the code indicate that: In our apollo server we get most of the errors as well formatter json and errors field, but there are some, e.g. related to incorrect query hash that come back as plain text. Possibly they are coming from some earlier layers? |
yeah, they are not very specific, and as well the library is not restricted to use those particular and then it's even worse if you consider future changes to server behaviors, or clear bugs. There is IMO just no reason to let serializer deserialize anything that isn't understandable by it. Especially the logic is already there to handle such errors. Now, the problem is that it is potentially a bit of a change to current users if for some reason they get responses that are not officially json but do parse correctly |
So... I still do not understant what do you want. Make a suggestion. |
Well, it's simple, currently we check the result of |
Ok, understand. |
When using persisted queries the server is expected to return BadRequest whenever hash isn't correct or wasn't registered yet.
Such responses are part of the process and come as plain text (html/text). This means they obviously can't be deserialized to any response type using neither System.Text.Json nor Newtonsoft, not even to an object.
At the same time the default
IsValidResponseToDeserialize
seems to be perfectly fine with passing such responses to the serializer.I can understand originally this behavior was introduced to allow for parsing validation errors (#419), but I don't think it was meant to be as permissive (disregard content type).
A workaround is obviously to provide an alternative implementation, but I simply don't see a reasony why one would ever pass something that is not json-like to a json serializer, while the method is very precisely called:
IsValidResponseToDeserialize
. BadRequest html/text is neither valid nor possible to deserialize.Current implementation:
NOTE: this is just one of the cases, but such errors can be returned in many other situations.
The text was updated successfully, but these errors were encountered: