tx tooltip shows "i-1 confirmations" for quite a while after transaction details window is already showing "i confirmations"

katesalazar commented at 6:32 pm on September 18, 2021: contributor

tx tooltip shows “i-1 confirmations” for quite a while after transaction details window is already showing “i confirmations”

Expected behavior

tx tooltip up to date with transaction details window

Actual behavior

tx tooltip shows “i-1 confirmations” for quite a while after transaction details window is already showing “i confirmations”. After receiving a new block. Several minutes!

To reproduce

Boot Bitcoin Core Qt, wait for a new block.

System information

Self-compiled v22.0 tag.

Contemporary Debian GNU/Linux, KDE 5.54.0, Qt 5.11.3, xcb. CPU is quite old, and disk interface is USB.

Other

Unconfirmed on testnet.

katesalazar added the label Bug on Sep 18, 2021

katesalazar commented at 7:35 pm on September 18, 2021: contributor

I have seen this twice on two different mainnet runs.

Then I run testnet and work OK.

Then I run mainnet again and happened again, after around ten minutes validating block 0000000000000000000c0d87f8e3e964f4b2238cff589a128b353108a2fb037b (height 701131).

It suppose it could be related to how an old computer and/or slow interfaces validate the blocks chain.

I wouldn’t know how to set up a test case so that I could try to bisect this.

katesalazar commented at 7:38 pm on September 18, 2021: contributor

Apparently the synced/unsynced low bar icon tooltip is immediately in sync with the transaction details window, while the transaction tooltip stays “one block late”.

katesalazar commented at 7:58 pm on September 18, 2021: contributor

Then I run mainnet again and happened again, after around ten minutes validating block 0000000000000000000c0d87f8e3e964f4b2238cff589a128b353108a2fb037b (height 701131).

Without closing Bitcoin Core Qt, next thing I knew, it is at block 0000000000000000000ca61f80e4b2e93961da04166f9911608262cd8b609335 (height 701135) with every label correctly in sync. But it has just been frozen for several seconds.

jarolrod commented at 11:20 pm on September 22, 2021: member

Thank you for reporting this. I am able to confirm that the tool-tip lags behind the actual confirmation count.

jarolrod commented at 2:40 am on September 23, 2021: member

This is confined to initial startup. Upon startup it does infact start with i-1 in the case where blocks need to be processed because the client had not been online. If the client is caught up, then restarted, the tooltip for a transaction will not display i-1 confirmations.

katesalazar commented at 5:45 pm on September 23, 2021: contributor

jarolrod commented 18 hours ago: Thank you for reporting this.

Thanks to @diegoviola who discovered this independently a couple of days ago.

katesalazar commented at 3:00 pm on September 25, 2021: contributor

I wrote: But it has just been frozen for several seconds.

That must be just how “GUI event loop should be block free (17145)” appears on my low end and very old hosts.

hebasto commented at 8:26 pm on September 30, 2021: member

It seems the relevant code: https://github.com/bitcoin-core/gui/blob/571bb94dfb5047c9be8fcbae5dae71de7256b86c/src/qt/transactiontablemodel.cpp#L586-L587

katesalazar commented at 7:54 am on October 14, 2021: contributor

I think all it lacks could be just one new call to TransactionTableModel::updateConfirmations() at some precise location.

tx tooltip shows “i-1 confirmations” for quite a while after transaction details window is already showing “i confirmations” #429