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 the user can produce faulty requests, in which case the backend responds with 400 BadRequest. An example of this is requesting: /objects/study?page=asdf (page query parameter needs to be a number)
However, there is no specified error page for these situations and the frontend seems to instead direct to the 500 error page. Thus, a 400 error page should be added that informs the user what went wrong with the request.
DoD (Definition of Done)
A bad request results in a comprehensive status code 400 error page and includes error details.
Testing
Unit, integration, e2e
The text was updated successfully, but these errors were encountered:
maybe instead of an actual error page, more suitable would be a snackbar. The idea is not to interrupt the user flow if it happens in the middle of an wizard action. The thought process here is that 401, 403 and 500 pages reflect actions or scenarios that are breaking for the user process, while 400 a bad request should not be like that.
Proposed solution
Currently the user can produce faulty requests, in which case the backend responds with
400 BadRequest
. An example of this is requesting:/objects/study?page=asdf
(page query parameter needs to be a number)However, there is no specified error page for these situations and the frontend seems to instead direct to the 500 error page. Thus, a 400 error page should be added that informs the user what went wrong with the request.
DoD (Definition of Done)
A bad request results in a comprehensive status code 400 error page and includes error details.
Testing
Unit, integration, e2e
The text was updated successfully, but these errors were encountered: