This commits does a few things:
1) Adds cache of token amount to the GetWalletToken endpoint, used by
mobile, in case the user is offline.
2) Split circuits by chain-id (when available) and by host+index when
not
3) It makes GetWalletToken always refresh, as that's directed from an
user action and we want to respect that. A cool down of 10s should be
added in the future to avoid spamming.
- Addressed the issue where remote image URLs failed to be processed due to local file handling restrictions.
- Introduced `FetchAndStoreRemoteImage` to download and save remote images to a temporary file, enabling compatibility with existing processing functions.
- Split the main image handling logic into smaller functions (`OpenAndDecodeImage`, `AdjustImage`) for better modularity and maintainability.
- Updated `OpenAndAdjustImage` to use these new functions, ensuring a streamlined flow for both local and remote images.
- Added cleanup steps for temporary files to prevent resource leaks.
resolves: #15691
* chore_: unused `BuildTx` function removed from the processor interface and types that are implement it
Since the `BuildTx` function is not used anywhere, it's removed from the code.
* fix_: resolving nonce improvements
When the app sends more than a single tx from the same account on the same chain, some
chains do not return appropriate nonce (they do not consider pending txs), because of
that we place more tx with the same nonce, where all but the first one fail.
Changes in this PR keep track of nonces being used in the same sending/bridging flow, which means
for the first tx from the multi txs the app asks the chain for the nonce, and every next nonce is resolved
by incrementing the last used nonce by 1.
Fixes https://github.com/status-im/status-desktop/issues/15930
The issue happened because I received a notification about a contact request, but the request was not associated with a message in the DB. The DB didn't have a message with the required ID in it.
This potential fix moves the creation of the contact request later in the handling code, because the only way this bug can happen as far as I see it is if there is an error later in the handler function and the message is never added to the response, and therefore never saved.
The Router algorithm is checking all the routes in order to find one the user has a balance to execute it
even that one is not the cheapest one. But if the user has some balances, but not enough to execute any
of suggested routes, we we're returning the last route which was checked, with the changes from this commit
we will return the last route for which the user has some balance, but not enough.
- Return errors from fetchBalancesForChain and GetBalancesAtByChain instead of silently ignoring them.
- Use cached balances if fetching new data fails, preventing empty wallets and ensuring data consistency.
- Fixed unit tests that was expecting GetBalancesAtByChain to always return nil error
Closes#15767
Co-authored-by: belalshehab <belal@status.im>