initialblockdownload set to false prematurely #26432

<!-- Describe the issue -->

Expected behavior

getblockchaininfo.initialblockdownload stays true until all blocks are imported

Actual behavior

getblockchaininfo.initialblockdownload becomes false before before all blocks are imported:

2022-11-01T11:16:39Z UpdateTip: new best=00000000000000000006f01ad0649cefc26c86c24a2808109c584bdcdc0d5293 height=761091 version=0x20f0c000 log2_work=93.816484 tx=776463417 date='2022-10-31T11:13:46Z' progress=0.999730 cache=338.3MiB(2269631txo)
2022-11-01T11:16:39Z Leaving InitialBlockDownload (latching to false)
2022-11-01T11:16:42Z UpdateTip: new best=000000000000000000078315da1efb6937a0d06015891b0412164dc2531e3004 height=761092 version=0x20c00000 log2_work=93.816497 tx=776466523 date='2022-10-31T11:29:40Z' progress=0.999733 cache=338.7MiB(2273000txo)
<snip 162 lines of UpdateTip>
2022-11-01T11:16:57Z UpdateTip: new best=00000000000000000004656d346fbac96ddcec6ee31b6abd696a241cd6994181 height=761255 version=0x2e4a6000 log2_work=93.818629 tx=776748676 date='2022-11-01T11:09:42Z' progress=0.999999 cache=375.6MiB(2573669txo)

Observe the 15 seconds it took my (reasonably fast) machine to import the remaining blocks. This is a problem for me since my application relies on this field to determine if syncing is complete. We can not rely on getblockchaininfo.verificationprogress either due to #26433

<!--- What was the actual behavior (provide screenshots if the issue is GUI-related)? -->

To reproduce

<!--- How reliably can you reproduce the issue, what are the steps to do so? -->

Start a node that hasn't been synced in a while and observe the log output.

System information

Observed on version 22 from the website.

<!-- What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->

<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->

<!-- GUI-related issue? What is your operating system and its version? If Linux, what is your desktop environment and graphical shell? -->

<!-- Any extra information that might be useful in the debugging process. -->

<!--- This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred. -->

IBD does not indicate whether your node is synced. As the RPC help indicates, this is only debug information for developers or users that want to debug P2P behavior.

Whilst it might be debug information only, it does appear to me also that IsInitialBlockDownload() should be returning as True during reindexing:

https://github.com/bitcoin/bitcoin/blob/5668ccec1d3785632caf4b74c1701019ecc88f41/src/rpc/blockchain.cpp#L1255

https://github.com/bitcoin/bitcoin/blob/5668ccec1d3785632caf4b74c1701019ecc88f41/src/validation.cpp#L1528-L1538

So perhaps what is happening here is that the node finishes importing before it has made a connection and receives new headers, so leaves IBD, then learns of a new header tip and starts processing those blocks as normal? Due to the DEFAULT_MAX_TIP_AGE check this should only be able to happen if the tip is less than 24h old. @sander2 If you are going to be turning the node on and off for <24h and need this check then perhaps you want to consider a different approach, such as comparing your tip/height to the tip served by some public block explorers' APIs?

Closing for now. Let us know if you have any other questions.