[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

[neil-marcellini]

Still holding, making some progress on that issue.

[neil-marcellini]

Still on hold

[neil-marcellini]

ditto

[neil-marcellini]

I'm taking this off hold now that the PR for error handling on manual requests is under review.

[neil-marcellini]

I'm starting on this now for the reason outlined here when closing the other issue.

[neil-marcellini]

I'm checking on the priority of this issue in Slack here

[neil-marcellini]

Based on that Slack conversation, we decided that this is pretty low priority and we don't need anyone working on it right now. It has been moved to wave6 since wave5 has changed it's focus from working on the free plan, to deprecating it.

This issue is a small project that probably needs to go through the #whatsnext process, including a small design doc. You will have to decide if this should be implemented using an error handling approach, or using violations. Both are a decent amount of work. It's open for anyone to pick it up, and I’m happy to answer questions and give some guidance to whoever takes it on.

For now, once again, goodbye 👋

[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!

[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!

[melvin-bot]

@neil-marcellini, this Monthly task hasn't been acted upon in 6 weeks; closing.

If you disagree, feel encouraged to reopen it -- but pick your least important issue to close instead.