-
Notifications
You must be signed in to change notification settings - Fork 60
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
Response status lost when error body parse fail #23
Comments
There's no way for NetworkResponseAdapter to know if the received response was valid or not. That's for your JSON deserialization library to handle. If you can provide a small example here to illustrate your usecase, I can look into it. Otherwise, this is working as intended. |
I have the same problem. As an example, my server sends json error responses that we can parse, but for a 429 Too Many Requests response, AWS sends the error response, and not my server. That error response is not parsable, because the json differs from what our own server sends. In this case, we get an "UnknownError" with a json parse exception. This doesn't tell us anything about the problem, and I can only show a general message to the user. If UnknownError would have an optional status code, we can at least know what went wrong and present something useful to the user. |
Makes sense. I'll try to experiment with a design in which |
I'm in an exact same situation here. Our Rest api throws different Error Json responses differentiated by their status code. I do not want to parse all of the error messages I just need to know the 4xx status code to act accordingly. |
Sorry for the long wait on this issue. I spent some time investigating it today. Here are my findings:
The fields will only be unpopulated in a weird scenario where the server responds with a success code and an invalid response body, so I don't think it could be a major problem. Expect a new release with these fixes soon. Thank you everyone for reporting it. |
When receiving an error response, if body parse fails we lose the reponse status code.
Since it is really a valid response, I think it is plausible to return as ServerError with empty body instead of UnknownError.
The text was updated successfully, but these errors were encountered: