Open nondiremanuel opened 1 week ago
One approach could be for the getinfo
command, which the GUI calls every 10 seconds for a local backend, to return the timestamp of the last poll, if any (note that we don't currently store this value). Then the GUI can check this value when it opens and consider the wallet to be syncing until the first poll, i.e. the first change of this timestamp.
For Liana Connect, we could leave this timestamp empty for now as a wallet using Liana Connect as a backend will remain synced even when the GUI is closed. As such, we would need to make sure the check of this timestamp is only done for a local backend.
For a local backend, I think this check on first poll completing could be done instead of the check on wallet height becoming positive in #1370 in order to cover opening both new and existing wallets, but for a Liana Connect backend, we would still need to check the height.
One approach could be for the
getinfo
command, which the GUI calls every 10 seconds for a local backend, to return the timestamp of the last poll, if any (note that we don't currently store this value). Then the GUI can check this value when it opens and consider the wallet to be syncing until the first poll, i.e. the first change of this timestamp.For Liana Connect, we could leave this timestamp empty for now as a wallet using Liana Connect as a backend will remain synced even when the GUI is closed. As such, we would need to make sure the check of this timestamp is only done for a local backend.
For a local backend, I think this check on first poll completing could be done instead of the check on wallet height becoming positive in #1370 in order to cover opening both new and existing wallets, but for a Liana Connect backend, we would still need to check the height.
If we go with something like this we are relying on the fact that the poll is 100% successful. Is there any possible instance in which the first poll completes but the wallet doesn't get updated for some reason? This would get the user in an even worse state than what he has now - i.e. syncing "done" but still a wrong balance shown.
Is there any possible instance in which the first poll completes but the wallet doesn't get updated for some reason?
We can be sure that if the poller completes, the wallet will have been synced to the extent that we're able to, ignoring some unlikely edge cases that would be logged as errors, and its height as stored in the DB will match the blockchain. So I think the first poll completing is a reliable indicator that the wallet has been synced.
This is part of the "Wallet syncing / scanning state at wallet opening" activity included in v8.
The requirement would be to have the same syncing interaction that was developed for a new wallet (#1370) to when a user opens a wallet already present in his Liana until the first poll runs. This would mean for the user to have a syncing state for a maximum of
30 sec (poller frequency) + poll execution time
every time he opens the wallet. In that time, the user would see the last known amount blinking and a text indicating that the syncing has not yet been completed.If we are worried that this could be detrimental for users that open the wallet frequently, we could potentially evaluate to have this behavior only if the wallet has not been open for a while (>
arbitrary threshold
). I personally think it's more consistent to keep it for every opening.One way that was thought to achieve this requirement was to get the blockchain height and compare it to the wallet height, but since the mismatch between this two values occurs also in different moments than the wallet opening, this would mean repeating the syncing behavior every time we detect the block height to raise until the next poll, which is not ideal imho (see: https://github.com/wizardsardine/liana/issues/1362#issuecomment-2402359386). We decided to explore different ways of approaching it and see what could be best.