chore(wallet)_: split getWalletTokenBalances into multiple functions
Removed some unused balances methods from wallet API
chore(wallet)_: refactored FetchOrGetWalletTokenBalances
- getWalletTokenBalances only returns cached ones
- update of balances is done in a separate method
chore(wallet)_: fix isVisible in getWalletTokenBalances is overwritten
It is overwritten and in some cases its value is desrespected
chore(wallet)_: simplify getWalletTokenBalance even further
chore(wallet)_: remove accountsDB from wallet.Reader
Call GetTestNetworkEnabled from NetworkManager instead
chore(wallet)_: remove rpc.Client from wallet.Reader.
Added GetActiveNetworks() method for NetworkManager
Removed adding native tokens from networks, as this is done already
in NetworkManager
chore(wallet)_: moved Persistence to token package
As it works with token_balances table, moved Persistence to token package.
Fixed TokenManager's Mark/Get previously owned tokens to use persistence
storage instead of direct SQL calls.
Introduced StorageToken that aggregates Token type, because when
Persistence moved to token package, names clash
test(wallet)_: tests for wallet.Reader.FetchorGetCachedBalances
- Get rid of InsertTestMultiTransaction function in test utils and
use InsertMultiTransaction method of transaction manager
- Use MultiTransaction type instead of TestMultiTransaction
Added a missing wallet DB migration file for multi transactions
This commit fixes a special case where the activity filter incremental
updates were reported as new even that they were present in a previous
update.
Updates status-desktop #12120
Refactor the activity filter session API to account for the new structure
Also:
- Refactor test helpers to mock for different chains with mixed answers
- Test implementation
Updates status-desktop #12120
Switch from the prototype of duplicating the SQL filter as a runtime
and keeping them in sync on each event that might invalidate the current
filtered entries to a simpler approach of requesting the filter again
and doing the diff to detect the new changes.
Also add a new reset API to model the new entries design requirements.
The new approach shows less corner-case to handle and follows one source
of truth concept making debugging and future maintenance easier.
Other changes
- Fix pending mocking to work with multiple calls
- Refactor tests to account for the new changes
Updates status-desktop #12120
This commit introduces the first steps towards implementing a session-based activity API to support dynamic updates of the current visualized filter in the wallet activity service. This change is necessary to move away from static paginated filtering, which was previously done in SQL, to a more dynamic approach that can handle updates in real-time.
The main changes include:
- Add basic `EventActivitySessionUpdated` support for pending transactions.
- Added a `TODO.md` file outlining the plan and requirements for dynamic activity updates.
- New session-related API to the `activity.Service`
- `session.go` contains the logic for session management and event processing related to activity updates.
- Add test case for incremental filter updates.
The commit also includes:
- various other minor changes and refactoring to support the new session-based approach.
- Deprecation notices added to the `api.go` file for methods that are no longer used by the status-desktop application.
- Clarification comments added to the `scheduler.go` file regarding replacement policies.
Updates: #12120
ghstack-source-id: a61ef74184
Pull Request resolved: https://github.com/status-im/status-go/pull/4480
The reading of the amount for pending transactions was done in the same
way as for transfers table. However, the transfers table has a string
hex representation of the amount, while the pending transactions table
has a binary representation of the amount (*big.Int). This was
triggering the not int warning and value was missing.
Updates status-desktop #12120
In case both to/from addresses are present in the list we were using
the same logic as for transfers. However, this doesn't make sense given
that we can have only one entry in pending activity.
The following cases are still covered
- When the receiver is in addresses we get received
- When both receiver and sender are in the list will get sent
- When the sender is on the list we will get sent
Updates status-desktop #12120
The activity type filtering was not stable in relation to addresses
filter which was generating unexpected Send/Receive type in the
corner-case when both sender and receiver was in the address list.
Updates status-desktop #11960
Brings consistency in case when sender and receiver are both in the
filter address list. This fixes the case of sender and receiver in
addresses and filters out duplicate entries.
Also
- refactor tests to provide support for owners
- adapt TestGetActivityEntriesWithSameTransactionForSenderAndReceiverInDB
to the use of owner instead of from
Trigger async fetching of extra information on each activity filtering
request. Only emit the update event for incomplete entries.
Other changes:
- Make DataEntry light as event payload by making all the fields
optional
- Add new required fields to the activity DataEntry
- Add collectibles.ManagerInterface to aid testing
Note: this PR keeps compatibility with current master by always
providing non-optional multi-transaction ID. The TODO will be executed
before merging the status-desktop PR.
Experienced a hang on FetchAssetsByCollectibleUniqueID call with:
[{{5 0x21263a042aFE4bAE34F08Bb318056C181bD96D3b} 1209},
{{5 0x9A95631794a42d30C47f214fBe02A72585df35e1} 237},
{{5 0x9A95631794a42d30C47f214fBe02A72585df35e1} 236},
{{5 0x9A95631794a42d30C47f214fBe02A72585df35e1} 832},
{{5 0x9A95631794a42d30C47f214fBe02A72585df35e1} 830},
{{5 0x9A95631794a42d30C47f214fBe02A72585df35e1} 853}]
Updates status-desktop #11597
dlipicar
Emil Sawicki
Ivan Belyakov
Khushboo-dev-cpp
Sale Djenic
Stefan