search

pendulum-chain / vortex

1 stars 0 forks source link

Fallback to V1 Squidrouter API if bridge-swap route is not found. #124

Closed gianfra-t closed 1 week ago

gianfra-t commented 1 month ago

Context

The prototype currently uses Squidrouter's API plus (https://github.com/pendulum-chain/vortex/blob/polygon-prototype-staging/src/services/squidrouter/route.ts#L113) to fetch the data required for initiating the swap and bridge call with the contracts. This corresponds to V2 version of the squidrouter application.

It has happened in the past that this API was not able to create a route, yet seems to be that the V1 API was working fine at the time.

Todo

Add fallback logic when the route cannot be obtained such that we attempt to get a route from the V1 API https://api.squidrouter.com/v1 instead.

prayagd commented 1 month ago

Hey team! Please add your planning poker estimate with Zenhub @bogdanS98 @ebma @gianfra-t @TorstenStueber

TorstenStueber commented 1 month ago

Is there any advantage to use V2 in the first place? Can V1 deal with both USDC and USDC.e or could it also be that it doesn't find a route at certain times while V2 finds a route?

gianfra-t commented 1 month ago

We initially didn't get the routes for one of the tokens consistently when using V1. That's why we switched. But it could also be, we just have anecdotal evidence.

ebma commented 1 month ago

We could do some experiments to test if v1 and v2 continue to return routes or not but I don't think it's worth the time as the squidrouter team could change something about it any time and then we'd have to do it again. IMO we should continue first querying apiplus (v2) and only consider v1 as a fallback, as we have to assume that the returned routes are different but better as briefly mentioned in a tooltip here.

image
ebma commented 2 weeks ago

While looking at this again, I realized that it actually doesn't make sense to implement this. When we created this ticket we had the assumption that in the past we were initially using squid v1 to get the routes and with changing to the apiplus... endpoint we switched to squid v2. As we noticed during the debugging of the recent Squidrouter contract problems, we have never ever used squid v1. It doesn't work for our use case as it doesn't support the posthooks we need to define. Thus, it also doesn't make sense to implement a fallback to squid v1.

What we could do is switch between the two endpoints that are apparently available for squid v2, namely https://v2.api.squidrouter.com/v2 and https://apiplus.squidrouter.com/v2. While the documentation still mentions both, see here and here, I would personally assume that they just forgot to fix all occurrences of the old one. I would expect them to deprecate https://v2.api.squidrouter.com/v2 soon as it doesn't make much sense for them to maintain two different endpoints for providing the same functionalities. Thus, I would propose we don't add a fallback between these two endpoints as we don't know if/when they decide to turn it off.

TorstenStueber commented 1 week ago

Yes, I agree @ebma. So let's not add a fallback but implement this ticket instead to check whether a route is available and show a graceful error message to the user to try again later.

I will close this issue.