TKDickson
commented
1 day ago I remembered the existence of #5964 today, which used to document a silent failure in editing address in letters, under specific circumstances. We've significantly re-architected the app (BE and FE) since that point, and the staging user I have on the ticket no longer has the same authorized services in staging (lettersAndDocuments true, userProfileUpdate false) to be able to determine the 'true' behavior in the app (key here: which of the many contact-info-related API calls would fail? what would they return in their fails? how would the app UI react to that now?).
If I mock that authorized services setup, and then also use Charles to block/return a 403 for the validate endpoint, it does throw a snackbar. But I don't know for certain if that's how the APIs would behave today for a user in this type of situation, so it's not definitive.
Proposed Change
Research our current snackbar implementation and confirm all snackbars currently wait on API communication to complete? If any snackbars do not wait for an api to complete, can we fail to send a snackbar on timeout or excessive processing time? Can we trigger an api return at nearly the same time as the 'back' button on a given screen and erase the snackbar before it finishes rendering? Can we tinker with our snackbar dismissal code to ignore snackbar dismissals from navigation if the snackbar itself is a failure message?
Why Should We Prioritize?
Coding Time Estimation
3
Testing Considerations
Checklist