Page MenuHomePhabricator

[Cashtab] [p7 of 8] Only hydrate changed utxos
ClosedPublic

Authored by bytesofman on Feb 25 2022, 03:19.

Details

Reviewers
emack
Group Reviewers
Restricted Project
Commits
rABC4c1c9d13e21d: [Cashtab] [p7 of 8] Only hydrate changed utxos
Summary

T1683

This diff introduces the first working version of this feature.

Currently, this diff includes many console.log statements and has also reduced the refresh rate by a factor of 10. This is for testing purposes -- before this diff is landed, the comments will be removed, and refresh rate will be left unchanged (to be modified in its own diff).

However, I'll leave it there until we get to the end of this series of diffs -- then pull it out if it is not used.

X Add function isExcludedUtxo with unit tests (determines if a given utxo is in an array of utxos)
X Add function whichUtxosWereAdded with unit tests
X Add function whichUtxosWereRemoved with unit tests
X Add function addNewHydratedUtxos with unit tests
X Add function removeConsumedUtxos with unit tests
X Add function areAllUtxosIncludedInIncrementallyHydratedUtxos with unit tests
X Using the above functions, modify the update function in useBCH.js to only hydrate (that is, collect eToken info about) the utxos that changed since the last time update ran
_ Reduce the interval between calls to update, speeding up Cashtab refresh rate

Current state of Cashtab:
hydratedUtxoDetails is recreated each time the utxo set changes. This requires a series of slow API calls to SLPDB.

Cashtab after this series of diffs lands:
Only new incoming utxos are parsed by API calls to SLPDB. These are added to hydratedUtxoDetails. Consumed utxos are removed. The resulting hydratedUtxoDetails is then validated to ensure it includes all utxos in the wallet. In testing, this reduces Cashtab UI locktime after sending a tx by about 60%.

Test Plan

Send and receive all kinds of transactions. Try to do it quickly and break it. eTokens, multi-send, send and receive, the works. Create new wallets. Do the same thing. Rename wallets. Change between wallets.

Diff Detail

Repository
rABC Bitcoin ABC
Branch
utxo-mgmt-p7-of-8
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 18361
Build 36527: Build Diffcashtab-tests
Build 36526: arc lint + arc unit

Event Timeline

emack requested changes to this revision.Feb 26 2022, 05:54
emack added a subscriber: emack.

Tested across Chrome, Firefox, Extension Plugin, iOS and Android devices.

web/cashtab/src/hooks/useWallet.js
247

whichUtxosWereAdded, whichUtxosWereConsumed and removeConsumedUtxos from earlier diffs did not have basic input param validation, so suggest adding the following here prior to calling whichUtxosWereAdded.

if (!wallet ||
!wallet.state ||
!wallet.state.utxos ||
!wallet.state.hydratedUtxoDetails ||
!utxos) {

return

}

323

Good to know even the OG devs use this ancient method of analytics :) Remove prior to landing.

1148

This is updating every second rather than every 10 seconds.

Is this intentional? If so:

  • update comment above (line 1140) to indicate every 1s
  • consider whether the utxo object logging statements in useWallet.js (line 218) is necessary as it's constantly outputting to the browser console every second which may be adding to browser memory usage when a Chrome window has been left open in the background for long durations. In one instance I left it running for 20 mins and I came back to a laggy UI. Not consistently reproducible but it has happened twice. Chrome can get weird some times.
  • the diff holds up pretty well against manual spamming of transactions across XEC, eToken, changing wallets...etc however it's hard to simulate production load. In lieu of any automated performance test suites, is it worth getting T1973 in beforehand as a precaution?
This revision now requires changes to proceed.Feb 26 2022, 05:54

Removing console.log statements with only dev relevance, reverting refresh rate change, add validation for new approach

This revision is now accepted and ready to land.Feb 27 2022, 11:00