Page MenuHomePhabricator

[Cashtab] [chronik utxo handling p14] Force update to chronik format of utxo storage before wallet can be used
ClosedPublic

Authored by bytesofman on Sep 14 2022, 17:14.

Details

Summary

T2447

Depends on D11986

This diff removes the obsolete hydratedUtxoDetails key from wallet.state as a way to distinguish a chronik migrated wallet from a legacy bch-api wallet.

This allows the app to use existing functions to wait for the wallet's state to be updated to chronik before the user can use it, preventing errors from being thrown by trying to create transactions using bch-api formatted utxos.

Ultimately, the chronik migration wallet will have a much different structure. However this is handled in a different task and will require it's own stack. This approach will allow bch-api to be deprecated in the utxo battery. Optimization can come later.

Test Plan

npm start
Check dev console
Note dev console msg Active wallet is not valid, loading params from API
Note that UI locks while wallet loads
Check local storage and confirm that hydratedUtxoDetails is no longer in wallet.state
Send some txs
Change to a saved wallet
Note dev console msg Saved wallet is not valid, loading with latest parameters
Note that UI locks while wallet loads
Check local storage and confirm that hydratedUtxoDetails is no longer in wallet.state
Switch back to original wallet and note absence of dev console msg and faster loading

Diff Detail

Repository
rABC Bitcoin ABC
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

emack requested changes to this revision.Sep 20 2022, 08:47
emack added a subscriber: emack.

switching to another saved wallet in this patch results in this infinite loop where it switches back and forth between the two wallets by itself. Seems to be a more persistent version of what Kieran experienced.

This revision now requires changes to proceed.Sep 20 2022, 08:47

Resolve wallet activation issue

Resolve wallet activation issue

Summary of the issue with wallet activation

  1. Cashtab is always running the update(wallet) function on an interval. Because setting state is async, this function could be called on the old wallet before the new wallet is activiated...which could reset the active wallet to the previous wallet in some cases depending on the timing. This issue is existing in the app right now and is unrelated to the migration component of this diff.
  2. Cashtab has had a few migrations and attempted to implement them specifically. These functions are obsolete now that state is part of the wallet, so that the wallet needs to be resaved pretty much all the time. I removed some of these confusing exception loops and adopted a broader approach of always erring on the side of updating the wallet.
This revision is now accepted and ready to land.Sep 20 2022, 14:55