eth: speed up active account transaction discovery#4168
Conversation
Incoming ETH transactions are currently only discovered during the regular Etherscan history sync, which runs every five minutes to stay conservative with API usage. That means a mined incoming transaction can remain invisible for minutes even though Ethereum blocks are produced much faster. Add a short-lived foreground activity lease so the backend can identify ETH accounts the user is actively viewing. While such a lease is active, cheaply probe the remote balance and trigger a targeted full account update only when the balance changes. This improves mined incoming transaction discovery without polling full transaction history for every account more often, and the existing five-minute full sync remains the fallback.
| if !ok { | ||
| return nil | ||
| } | ||
| if active && backend.environment != nil && backend.environment.UsingMobileData() { |
There was a problem hiding this comment.
Is the updater fetching a lot of data? Otherwise, I'd skip the mobile data check. We possibly do the whole initial blockchain sync using mobile data, I don't see this as a big issue
| const account = accounts.find(({ code: accountCode }) => accountCode === code); | ||
| const isEthereumAccount = account !== undefined && isEthereumBased(account.coinCode); | ||
| const insured = account?.bitsuranceStatus === 'active'; | ||
| useAccountActivity(code, isEthereumAccount); |
There was a problem hiding this comment.
Could it make sense to move the eth check inside the hook to avoid duplicating it around? Also, a comment about why it's only needed for eth accounts could help
| } | ||
| ethAccount, ok := account.(*eth.Account) | ||
| if !ok { | ||
| return nil |
There was a problem hiding this comment.
Should not happen, but maybe a log to trace that this has been called for a non-eth account?
bznein
left a comment
There was a problem hiding this comment.
Just a couple of fly-by comments, I am reviewing a bit the eth updater in particular and will take some more time to do so :)
| // It does that in three different cases: | ||
| // - When a timer triggers the update. | ||
| // - When the signanl to update all accounts is sent through UpdateETHAccountsCh. | ||
| // - When a specific account is updated through EnqueueUpdateForAccount. |
There was a problem hiding this comment.
We should probably update the comment here a bit to reflect what the method does now
| return apiPost('accounts/eth-account-code', { address }); | ||
| }; | ||
|
|
||
| export const setAccountActivity = ( |
There was a problem hiding this comment.
I'll let someone from frontend confirm, but I think we tend to call api methods starting with either "get" or "post"
There was a problem hiding this comment.
Correct we usually prefix get request with getApiendpointname and often use the verb of the action for the post request.
Reading what account/${code}/activity does...
Add a short-lived foreground activity lease so the backend can identify ETH
accounts the user is actively viewing. While such a lease is active, cheaply
probe the remote balance and trigger a targeted full account update only when
the balance changes. This improves mined incoming transaction discovery without
polling full transaction history for every account more often, and the existing
five-minute full sync remains the fallback.
maybe activateAccout but this name is a bit confusing. focusAccount, postAccountActivity ... hm naming is hard :)
if it is ETH specific maybe move to api/eth.ts OR add ETH in the function name?
Sorry I dont have a good name, just some pointers 🙏
Fix to an old issue: #837
Incoming ETH transactions are currently only discovered during the regular Etherscan history sync, which runs every five minutes to stay conservative with API usage. That means a mined incoming transaction can remain invisible for minutes even though Ethereum blocks are produced much faster.
Add a short-lived foreground activity lease so the backend can identify ETH accounts the user is actively viewing. While such a lease is active, cheaply probe the remote balance and trigger a targeted full account update only when the balance changes. This improves mined incoming transaction discovery without polling full transaction history for every account more often, and the existing five-minute full sync remains the fallback.