[Cashtab] [WS update engine Part 4] On successful websocket connection, change wallet utxo refresh interval from 1s to 30s
ClosedPublic
Actions

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

Details

Reviewers

emack

Group Reviewers

Restricted Project

Commits

rABCeb9880c27f06: [Cashtab] [WS update engine Part 4] On successful websocket connection, change…

Summary

T2447

Depends on D11673

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

Start Cashtab with the legacy refresh rate of 1 second (this is how often an API call is performed to see if the utxo set has changed).

If the websocket connects successfully, reduce this rate to 30s (because the websocket connection will now trigger an update on demand when a new tx is seen).

Re-adjusting the refresh rate back to 1s on a websocket disconnect event was considered and rejected, as this should be properly handled by T2522. This means that if chronik goes down while a user has their browser open, the refresh rate will be slow until the websocket reconnects.

Test Plan

npm start
Check the dev console to see refresh rate
Send and receive transactions, see that wallet refreshes in line with the tx notification.
Try to break it. Send lots of txs at the same time, receive and send tx at the same time.

Diff Detail

Repository

rABC Bitcoin ABC

Branch

variable-update-interval

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 19521
Build 38770: Build Diff	cashtab-tests
Build 38769: arc lint + arc unit

Event Timeline

bytesofman created this revision.Jun 30 2022, 20:54

Herald added a reviewer: Restricted Project. · View Herald TranscriptJun 30 2022, 20:54

bytesofman requested review of this revision.Jun 30 2022, 20:54

Harbormaster completed remote builds in B19521: Diff 34204.Jun 30 2022, 20:57

Removing uncomment

Harbormaster completed remote builds in B19548: Diff 34237.Jul 4 2022, 21:25

If you send two inbound txs at the same time, one from another cashtab, one from electrumABC, notifications for both txs will show up instantly as expected. However while the first tx will get reflected in the tx history pretty quickly, the second one doesn't show up until about 30 seconds later, which feels like the 2nd one was somehow waiting for the default 30 second utxo refresh interval before revealing itself. Is this expected behavior?

This revision now requires changes to proceed.Jul 5 2022, 08:09

In D11691#262440, @emack wrote:

If you send two inbound txs at the same time, one from another cashtab, one from electrumABC, notifications for both txs will show up instantly as expected. However while the first tx will get reflected in the tx history pretty quickly, the second one doesn't show up until about 30 seconds later, which feels like the 2nd one was somehow waiting for the default 30 second utxo refresh interval before revealing itself. Is this expected behavior?

Good catch.

I'll need to do some testing with added console.log statements to see how they are specifically being handled by Cashtab. Seems most likely a race condition from React's asysnc state --- i.e., what happens when update is called by the first tx, sets the refresh rate to 30s -- while a simultaneous inbound tx is setting it back to instant (before the call to set to 30s? after? same time?).

At any rate, the 30s 'cleanup' interval is at least working as expected.

From here,

I'll do some more tests with console.log statements to see if I can get more specific info about what is happening / see if there is some approach to catch these cases
I think most likely outcome is that we will always have an edge case here due to react's async setState, in which case we should consider a tighter cleanup interval than 30s.