Many API endpoints return a boilerplate error message if certain conditions aren't met, chiefly whether the current user is logged in and their session is valid. These are largely producing responses in the form of Msg::no_login(), which returns a seemingly successful response with an error message - yuck.
Unfortunately, a lot of our recent tooling of the front-end means these API responses aren't being handled appropriately. Ideally, an error response performs the following:
Returns an appropriate response code (not 200!)
Unloads and destroys the session, if it wasn't done so already and the action is appropriate (e.g., no login)
Returns an appropriate response message
1525 already begins the work of better handling invalidLogin states but other parts of the front-end do not behave well when a seemingly successful API response doesn't actually include expected payload data, like any React Query onError hooks.
Many API endpoints return a boilerplate error message if certain conditions aren't met, chiefly whether the current user is logged in and their session is valid. These are largely producing responses in the form of
Msg::no_login()
, which returns a seemingly successful response with an error message - yuck.Unfortunately, a lot of our recent tooling of the front-end means these API responses aren't being handled appropriately. Ideally, an error response performs the following:
1525 already begins the work of better handling
invalidLogin
states but other parts of the front-end do not behave well when a seemingly successful API response doesn't actually include expected payload data, like any React QueryonError
hooks.