Add graceful error handling for failed route quotes

[nikarm22]

Tickets:
Route Errors

UI:

[netlify]

👷 Deploy request for wormhole-connect pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	16f1120

[netlify]

👷 Deploy request for wormhole-connect-mainnet pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	16f1120

[Wesleyleung]

This might be impacted by @artursapek's change of removing the concept of route availability in this PR: #2535

In this case, the route would just not show anymore at all. You two might be want to sync up to discuss how to reconcile this case.

It would still be useful to give the user feedback. So if the routes do not show but we are able to get back an error message, we can show it under the input amount field (similar to the existing message about entering an amount exceeding your wallet balance)

[artursapek]

@Wesleyleung fair point. right now I dont think the isAvailable interface is doing that very well, or even intended for that. that was originally meant as an "is the relayer online and responsive right now?" check.

to surface errors when fetching a quote, the correct way would be to aggregate them from the "get quote" responses. that's where we would have errors like "amount is too small" etc. however there's the question of how we handle multiple responses... we could have any combination of 1 or more errors, and 1 or more successful quotes. do we show the errors when we had at least one successful quote? if we have multiple errors, how do we pick which one to show?

it's probably best to have structured errors, so that "minimum amount" is a standard type we know about and can take the minimum of if there's multiple of these errors, for example.

doing this properly is definitely a biggest task.

[nikarm22]

@artursapek with current fix, it's displaying quote error in the Route box, which has a failed qoute request. I don't think it's interfering with isAvailable logic at all tho. Also Amount might be low for some routes, but not for others, so generalizing errors in one place is losing context.

[Wesleyleung]

I think standardizing error types and aggregating them makes sense.

As a quick fix, I think keeping the "greyed out" route concept with a "local" error message like what Armen has is ok until a more complete solution can be done properly.

A better UX could be to structure these error types such that if at least 1 or more route is successful, show them and do not produce an error in the UI (show in console though). Then, as an example, if I type in too low an amount where all routes would become "disqualified", I would see a single error message and zero routes. This single error message would tell the user to type in the common floor amount among all returned error thresholds.

Example:

1. Type in 0.01 sol

• Mayan: min 0.05 sol
• Automatic route: min 0.15 sol
• X route: min 0.2 sol

Error message: "Amount too small (min ~0.05 sol)"
Route UI state: show none
Console: output all individual errors

2. Type in 0.05 sol
   Error message: none since at least 1 route qualifies successfully
   Route UI state: show Mayan route, others still don't show
   Console: output the error messages of the routes that didn't qualify

As I type in higher amounts, more routes that qualify would progressively show.

I'm not sure what are the other error types that can be structured in this way other than min, but we can start with this one and as we find more, come up with a structure for them where a common denominator can be determined to tell the user when there are more than 1 of that error type.

[Wesleyleung]

Adding @kev1n-peters for thoughts too

[Wesleyleung]

There's also the case where there are distinct error types to compare: min amount type vs something else, and we would need to come up with logic to disambiguate those.

[kev1n-peters]

The SDK should return structured errors that are route agnostic. Created this issue for tracking: wormhole-foundation/wormhole-sdk-ts#690

[emreboga]

There a few comments, rest is LGTM!

[emreboga]

LGTM!