You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our Astroport PCL integration test for candidate routes test_astroport_tokens proved to be flaky.
Investigations pointed at the fact that sometimes the top liquidity Astroport PCL pool contains uosmo and another token (e.g. AXL)
However, due to pairing with uosmo (a token that is in many pools), the candidate route algorithm would not iterate far enough to reach the PCL pool.
In this specific example, the chosen candidate route pool was intended to be 1616
If AXL were to be give as token in, the pool would be found
There are multiple possible solutions to this problem:
Run the candidate route search algorithm by starting to search from token in, then starting to search from token out
Downside: affects performance
Track Astroport PCL pools via config
Downside: not an extensible solution. Would not solve the problem for other pool types
Prioritiize direct routes
Downside: also not always a superior approach
Increase max candidate rotues
Downside: affects performance
Reimplement candidate route algorithm via DATA-174
The last approach is superior and should account for this detail during re-implementation. As a result, for now, we keep this ticket open for tracking purposes
The text was updated successfully, but these errors were encountered:
Our Astroport PCL integration test for candidate routes
test_astroport_tokens
proved to be flaky.Investigations pointed at the fact that sometimes the top liquidity Astroport PCL pool contains uosmo and another token (e.g. AXL)
However, due to pairing with uosmo (a token that is in many pools), the candidate route algorithm would not iterate far enough to reach the PCL pool.
In this specific example, the chosen candidate route pool was intended to be 1616
If AXL were to be give as token in, the pool would be found
There are multiple possible solutions to this problem:
The last approach is superior and should account for this detail during re-implementation. As a result, for now, we keep this ticket open for tracking purposes
The text was updated successfully, but these errors were encountered: