Include stack trace when reporting MalformedServerResponseException #1083
Labels
a-api
Implementing specific parts of the Zulip server API
Milestone
Comments
gnprice
added a commit
to gnprice/zulip-flutter
that referenced
this issue
Nov 25, 2024
For a malformed-response error this is essential because it pinpoints where in the data schema the mismatch occurred between our expectations and the server's behavior. There's more to do here (zulip#890 for getting this to the user in cases like a malformed response, so they can screenshot it when reporting an issue; zulip#1083 for including stack traces when relevant in showing other errors to the user) but this is a start.
chrisbobbe
pushed a commit
that referenced
this issue
Nov 25, 2024
For a malformed-response error this is essential because it pinpoints where in the data schema the mismatch occurred between our expectations and the server's behavior. There's more to do here (#890 for getting this to the user in cases like a malformed response, so they can screenshot it when reporting an issue; #1083 for including stack traces when relevant in showing other errors to the user) but this is a start.
|
Hello, I have opened PR #1374 for fixing this issue - PTAL, Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When a request to the server fails, we typically show an error to the user. (The main gap in that is #890, which we should fix.) The details of the error can be useful, particularly if the user takes a screenshot of them to include in reporting the issue to us.
If the cause of the error is that the server's response doesn't match our expectations — a MalformedServerResponseException — then a key thing we want to know is where in the schema the mismatch occurred: what field of what type of object. That information isn't in the error message itself, but it is in the stack trace. For example see this error caused by #1082.
So we should show the stack trace when reporting a MalformedServerResponseException. This is most important for a registerQueue request (#890) just because that's the most sprawling data schema; but it can matter for other request types too.
The text was updated successfully, but these errors were encountered: