Skip to content

unify the query error handling #1176

Open
@ollibowers

Description

@ollibowers

(Probably blocked by useQuery unification and the notification hook, maybe can work on it together)

Currently when an API request fails, we have a pretty inconsistent mix of console.error, throwing, and notifications.
This needs to be unified. Ideally, we will show an antd notification for certain errors, and throw to error boundary on others.

The main errors and how I believe they should be handled are as follows:

  • 400 Bad Request (body had wrong data): BAD, OUR FAULT, error boundary
  • 401 Unauthorized (token is bad, potentially from logout on another tab): notif
  • 403 Forbidden (token is good, but user is not setup, like adding to unplanned): notif
  • 404 Not Found: BAD, OUR FAULT, error boundary
  • 422 Unprocessable Content (pydantic cried): BAD, OUT FAULT, error boundary
  • 500 Internal Server Error: BAD, OUR FAULT, error boundary
  • anything else, probs error boundary??? maybe notification??? discuss with directors

Note that if any of the notification ones happen on a useQuery (when we are getting data), then its a bit unclear how it should be further handled with the absense of data. Discuss these cases with directors as they come up.

The notification should be consistent, and have info about what went wrong. You can investigate throwOnError in react query to filter out the non throws, then do some logic to handle when it doesnt throw. This can also be set globally in the App.tsx where the query client is created.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions