Frontend handling of other failures - Githubissues

HHS / OPRE-OPS

ACF's OPRE OPS product. Code name Unicorn.

Other

12 stars 3 forks source link

Frontend handling of other failures #1262

Open jonnalley opened 1 year ago

jonnalley commented 1 year ago

User Story

As an OPS user, I want to be gracefully aware of miscellaneous errors so that I'm not confused or frustrated.

Acceptance Criteria

[ ] Users will see an appropriate message when there’s been a failure to store or retrieve information not related to a user’s input
[ ] The application will not display developer-facing or default error messages and will instead gracefully catch and present errors

Tasks

[ ] Support 400-series and 500-series errors in the frontend that are sent from the backend
[ ] Determine what should be done, for scenarios that break a logic rule, but can’t be remedied by the user.

Definition of Done Checklist

[ ] Usability validated
[ ] UI works as designed
[ ] OESA: Code refactored for clarity
[ ] OESA: Dependency rules followed
[ ] Automated unit tests updated and passed
[ ] Automated integration tests updated and passed
[ ] Automated quality tests updated and passed
[ ] Automated load tests updated and passed
[ ] Automated a11y tests updated and passed
[ ] Automated security tests updated and passed
[ ] 90%+ Code coverage achieved
[ ] PR(s) have been merged to main
[ ] Design/tech debt eliminated
[ ] Build process updated
[ ] Documentation updated or added
[ ] Feature flags/toggles created

Additional Context & Resources

Currently, backend will throw 400 or 500 errors if there's some sort of service/DB/connectivity/session issue but we need that gracefully handled in the frontend

fpigeonjr commented 6 months ago

We have implemented a redirect to a generic error page if we experience server issues and can be tested with the simulated error prop as seen in #1474.