Skip to content

eth: speed up active account transaction discovery#4168

Open
Tomasvrba wants to merge 1 commit into
BitBoxSwiss:masterfrom
Tomasvrba:eth-incoming-tx
Open

eth: speed up active account transaction discovery#4168
Tomasvrba wants to merge 1 commit into
BitBoxSwiss:masterfrom
Tomasvrba:eth-incoming-tx

Conversation

@Tomasvrba

Copy link
Copy Markdown
Collaborator

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.

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.
@Tomasvrba Tomasvrba requested review from Beerosagos and benma May 27, 2026 10:22
@Tomasvrba Tomasvrba marked this pull request as ready for review June 10, 2026 09:16
@Tomasvrba Tomasvrba requested a review from a team as a code owner June 10, 2026 09:16
Comment thread backend/backend.go
if !ok {
return nil
}
if active && backend.environment != nil && backend.environment.UsingMobileData() {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread backend/backend.go
}
ethAccount, ok := account.(*eth.Account)
if !ok {
return nil

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not happen, but maybe a log to trace that this has been called for a non-eth account?

@bznein bznein left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 = (

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll let someone from frontend confirm, but I think we tend to call api methods starting with either "get" or "post"

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants