Add wallet events feed to TransactionManager and send pending changed
events on add and delete
Also
- Remove hardcoded values in the filter query
- Small improvement to query
Updates status-desktop #11233
This fixes returning address identity after that was changed by
the real to/from fix. Previously the address was wrongly used as from
Updates status-desktop #11233
Added test to validate the fix
Also change JOIN to LEFT JOIN between `multi_transactions` and `transactions` table so that we return all entries from `multi_transactions` table even if there is no matching entry in `transactions` table, which might be the case for multi transactions that that could not be detected. This will postpone the error case until we get into details of the multi transaction.
Updates status-desktop #11233
Implement activity.Scheduler to serialize and limit the number of
calls on the activity service. This way we protect form inefficient
parallel queries and easy support async and rate limiting based on the
API requirements.
Refactor the activity APIs async and use the Scheduler for managing
the activity service calls configured with one of the two rules: cancel
ignore.
Updates status-desktop #11170
Main changes:
- Refactor activity API to propagate token identities.
- Extend service to convert token identities to symbols for filtering
multi-transaction
- Filter transfers, pending_transactions and multi-transactions based
on the provided token identities
- Return involved token identities in activity API
- Test token filtering
Also:
- Fixed calling cancel on a filer activity completed task to release
resources
Notes:
- Found limitations with the token identity which complicates things
by not allowing to filter by token groups (like token-code does)
Updates status-desktop #11025
The new API returns all known recipients of a wallet, by
sourcing transfers, pending_transactions and multi_transactions tables
The API is synchronous. Future work will be to make it async.
In some corner cases, when watching a famous wallet, it can
be that there are too many recipients to be returned in one go. Offset
and limit can be used to paginate through the results.
Updates status-desktop #10025
Change smart contract with new API.
Update gas amount for deployment.
Add Burn() and EstimateBurn() functions.
Add RemainingSupply() functions.
Issue #10816
fetch strategy:
Before:
- block fetching commands for different accounts were in the same wait
group, making them dependent on each iteration.
- transfers loading command was checking database for new unloaded
blocks on timeout and was in the same wait group with block fetching, so
it was often blocked until all block fetching commands finish for
iteration.
Now:
- block fetching commands run independently for each account
- transfers fetching command is run once on startup for unloaded blocks
from DB
- fetch history blocks commands are launched once on startup for
accounts with no full history loaded
- transfers are loaded on each iteration of block range check
without waiting for all ranges to be checked
Refactor the filter interface to be an async call which returns
the result using a wallet event
A call to the filter API will cancel the ongoing filter and receive
an error result event
Closes status-desktop #10994
Main changes:
- extend DB query include status for transactions and pending_transactions
- extend DB query to aggregate data from complex activity entries
- extend tests to include the new status values
Other changes:
- Improve tests with mocked addresses in DB to have a true to/from state
Update status-desktop #10746