[LOW] Distance: Handle errors with geocoding for offline distance requests

[neil-marcellini]

Check out the original plan in the design doc: Handling errors with geocoding.

Since then, we've updated the desired UX as outline in this Slack conversation. Here's the current desired UX.

Here is how the flow currently works

1. Go offline
2. Request money > Distance
3. Enter invalid start and finish addresses
4. Click next
5. Choose a workspace
6. Click request
7. Go online
8. Lots of issues

Here's how it should work after going online

• The problematic request appears in the LHN as unread, with a red dot indicator. This matches the wave9 violations UX.
• There is a red dot on the distance row on the transaction report page
• Going back up the hierarchy, red dot also appears on the request preview in the expense report, and on the expense report preview in the workspace chat
• We must be able to open all reports that potentially failed to create. Workspace chat, expense report, distance transaction report
• After clicking on the distance row you are navigated to the distance request page and error messages are displayed under each invalid waypoint, instructing the user to edit them. When a waypoint is clicked the user can update the address and must use the suggestions which are now shown since they are online
• When a new address is saved we clear any errors on the waypoint
• When the save button is clicked we first make sure that all waypoints errors have been cleared, then call CreateDistanceRequest to try creating the request again instead of editing an existing request. We can identify that the request hasn’t been created yet because it doesn’t have a receipt.
  ❗ Note, this feels a bit sketchy. Is this going to work? Are we ok with the data only existing optimistically? Can we open all the chats without the request existing?
• When the request is successfully created, clear all errors and make sure all optimistic data is updated or replaced.
• Prior to retrying creation, the error messages can not be dismissed. If the user wants to give up they can delete the optimistic request with the normal delete flow and we must clean up all optimistic data.

[melvin-bot]

This issue has not been updated in over 15 days. eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[neil-marcellini]

On hold for Fix error handling when creating a request fails because we'll need to use a lot of that functionality.

[neil-marcellini]

Still holding