You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently errors that happen when rendering an html page (rather than a json response) are handled very poorly. No content is returned, or text error content is returned.
Add 404 page
Add 500 page
Handle 403 errors from API responses by clearing the token and redirecting to the homepage with a flash message prompting users to log back in.
We will also need to separate out the API error responses from the web html responses. I can think of a couple ways to do that.
a. Add a check to those error_handling routes for the Content-Type of the response and if it's text/html render the proper page or if it's application/json render the error properly. This will also play into the app's error handling in the error module, which implements the ResponseError trait.
b. Always return a 200 for api calls, but have an optional error field that any caller would have to check. This could work ok because all the api endpoints are used by webhooks which don't really care what the response is, and will work well with the standard way that GraphQL handles errors.
The text was updated successfully, but these errors were encountered:
Currently errors that happen when rendering an html page (rather than a json response) are handled very poorly. No content is returned, or text error content is returned.
All of this will need to be done using: https://docs.rs/actix-web/2.0.0/actix_web/middleware/errhandlers/struct.ErrorHandlers.html
We will also need to separate out the API error responses from the web html responses. I can think of a couple ways to do that.
a. Add a check to those error_handling routes for the Content-Type of the response and if it's text/html render the proper page or if it's application/json render the error properly. This will also play into the app's error handling in the error module, which implements the ResponseError trait.
b. Always return a 200 for api calls, but have an optional error field that any caller would have to check. This could work ok because all the api endpoints are used by webhooks which don't really care what the response is, and will work well with the standard way that GraphQL handles errors.
The text was updated successfully, but these errors were encountered: