Skip to content

Include stack trace when reporting MalformedServerResponseException #1083

Open
@gnprice

Description

@gnprice

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    a-apiImplementing specific parts of the Zulip server API

    Type

    No type

    Projects

    Status

    No status

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions