Closed saledjenic closed 1 hour ago
:grey_question: | Commit | :hash: | Finished (UTC) | Duration | Platform | Result |
---|---|---|---|---|---|---|
:heavy_check_mark: | 654ba937 | #18 | 2024-07-01 11:24:37 | ~4 min | ios |
:package:zip |
:heavy_check_mark: | 654ba937 | #12 | 2024-07-01 11:32:10 | ~11 min | linux |
:package:zip |
:heavy_check_mark: | 654ba937 | #12 | 2024-07-01 11:35:37 | ~15 min | android |
:package:aar |
:heavy_check_mark: | 654ba937 | #13 | 2024-07-01 12:12:07 | ~51 min | tests |
:page_facing_up:log |
:heavy_check_mark: | 9759e74d | #19 | 2024-07-01 11:49:09 | ~2 min | ios |
:package:zip |
:heavy_check_mark: | 9759e74d | #13 | 2024-07-01 11:52:14 | ~6 min | linux |
:package:zip |
:heavy_check_mark: | 9759e74d | #13 | 2024-07-01 11:53:22 | ~7 min | android |
:package:aar |
:heavy_check_mark: | 9759e74d | #14 | 2024-07-01 12:57:02 | ~44 min | tests |
:page_facing_up:log |
@ilmotta changes done here should not affect the mobile app since it doesn't respond to sing-transactions
signal (you will start using it when you implement keycard tx signing).
@ilmotta changes done here should not affect the mobile app since it doesn't respond to
sing-transactions
signal (you will start using it when you implement keycard tx signing).
@qfrank, since you will be touching transaction signing via keycard, this is probably of interest to you.
I added uuid
for async calls and also added an endpoint to stop async tasks, it can be used by the client when the sending modal is about to be closed.
Please check the third commit here this one, it's an important one, which is fixing the issue described here https://github.com/status-im/status-desktop/pull/15344#issuecomment-2196438083
It does this: If there are multiple routes across multiple networks, but the user doesn't have a positive balance on the network which the router initially suggested as the best (cheapest) route, then we are not returning an error saying there is not enough balance, but instead try to suggest the route on the network where the user has a positive balance even if that's not the cheapest route (it should be the second cheapest route, but if there is not enough balance on it we proceed with the third cheapest route and so on...).
What's done in this PR:
GetSuggestedRoutesV2Async
exposed viawallet
API which calculates the best route in an async way and notifies the client via"wallet.suggested.routes"
signal"wallet"
and event type "sign-transaction", like this{"type":"wallet","event":{"type":"sing-transactions", "transactions":["0x123", ...] .... } }
is now set to signal type"wallet.sign.transactions"
and looks like this{"type":"wallet.sign.transactions","event":["0x123", ...] }
"wallet.suggested.routes"
, it carries the best path (list of paths v2) or error (code and description)