In D11673#261805, @emack wrote:

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