Page MenuHomePhabricator

[Cashtab] [WS Update Engine Part 3] On websocket tx seen message, refresh the wallet utxo set
ClosedPublic

Authored by bytesofman on Jun 27 2022, 20:54.

Details

Summary

T2447

Depends on D11657

Part 3 (of 4 planned) stacked diff for converting Cashtab from a static refresh rate to an on-demand refresh rate depending on Websocket transaction messages

When the websocket sees a new transaction, clear the existing 30s interval and reset it to near instant. Then set it back after refreshing the walle utxo set.

In this way, the wallet is instantly updated when a new tx is seen --- instead of the current approach, which checks the API constantly to verify if any changes have occurred.

The figure 10 is arbitrarily chosen for the 'instant' interval reset because choosing zero causes the wallet to refresh multiple times before the function is reset.

This diff includes debug logs that are useful in the testing of this diff that will be removed in the final part of this stacked diff.

Test Plan

npm start
Receive a tx with the wallet
Note incoming tx notification and immediate balance update
Note that tick() does not appear multiple times in quick succesion in console.log
Send a tx with the wallet and note the same
Test with eToken

Diff Detail

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

Event Timeline

The build failed due to an unexpected infrastructure outage. The administrators have been notified to investigate. Sorry for the inconvenience.
emack requested changes to this revision.Jun 28 2022, 10:19
emack added a subscriber: emack.

I'm not seeing the logic subscribing to websocket tx seen messages in this diff even though it's in the description. The next part (Part 4) of this stacked diff series doesn't seem to cover this either. Does this have anything to do with the build failure above?

This revision now requires changes to proceed.Jun 28 2022, 10:19

I'm not seeing the logic subscribing to websocket tx seen messages in this diff even though it's in the description. The next part (Part 4) of this stacked diff series doesn't seem to cover this either. Does this have anything to do with the build failure above?

This uses the existing websocket subscription. The utxo refresh is triggered by calling setWalletRefreshInterval(10) inside processChronikWsMsg

Pseudocode:

  1. Chronik websocket sees a tx at an address the wallet is subscribed to (incoming or outgoing)
  2. processChronikWsMsg is called
  3. If the websocket msg was a tx confirmation or a new block found, processChronikWsMsg does nothing
  4. If the websocket msg was a new tx at the addresses, setWalletRefreshInterval(10) is called inside processChronikWsMsg. This changes the wallet refresh interval from 30 seconds to 0.001 seconds. The way useInterval works, this is clearing the existing interval and then setting up a new one that fires instantly -- so, effectively, the wallet updates its utxo set as soon as the tx is seen.
  5. Inside the update() function, there is a catch loop that checks walletRefreshInterval. If it sees that it is 10, it adjusts it back to the default.

Overall behavior -- routine API wallet refresh every 30s to cover a failed websocket connection, otherwise the wallet refreshes every time the websocket sees a tx.

This is a change from current behavior where the wallet pings the API every 1s to see if there are any changes to the utxo set. This is both less efficient (99.9% of the calls don't get any useful information), and slower (since the websocket usually fires in less than 1s).

This revision is now accepted and ready to land.Jun 28 2022, 23:41