keep restarting on error non-stop, removed some tests accordingly.
Fixed a flaky test for loadBlocksAndTransfers command.
Added tests for async.AtomicGroup.
Made tranfersCommand FiniteCommandWithErrorCounter to prevent infinite
restart.
mock it in tests.
Made a configurable timeout interval for Commander interface.
Added tests to verify loadBlocksAndTransfers command is stopped
correctly on max errors limit reached
proper handling of errors and commands restart.
Now:
- Infinite commands started only once and never restarted, stoped on
context.Done.
- Finite commands are joined into AtomicGroup to stop the rest in the
group in case one command fails. Otherwise other commands in the group
will continue running and the failed command is not retried to
restart. Fixed goroutine leakage in case of failure of some commands
`getLogs` for multiple accounts simultaneously. For now only used for
new transfers detection. Detection of `new` transfers has been changed,
now they are searched from head and forward. Previously they were
searched from last scanned block forward.
Refactored transfers loading to reduce blockchain RPC requests (getBaseFee, getTransaction,
getTransactionReceipt) by reusing preloaded transaction and block fee.
Split extraction of subtransaction from logs and from ETH transfer into
different methods.
Refactored log_parser to extract sender and receiver addresses
uniformly for different transfer types.
Replaced info logs with debug where needed.
closes#4221
Mainly refactor API to have control on pending_transactions operations.
Use the new API to migrate the multi-transaction ID from to transfers
in one SQL transaction.
The refactoring was done to better mirror the purpose of pending_transactions
Also:
- Externalize TransactionManager from WalletService to be used by
other services
- Extract walletEvent as a dependency for all services that need to
propagate events
- Batch chain requests
- Remove unused APIs
- Add auto delete option for clients that fire and forget transactions
Updates status-desktop #11754
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