Block height off by one error?

[neunenak]

When running wallet operations (e.g. wallet balance) with INFO level logging turned on, I've seen logs that I think are showing that ord is trying to fetch a block height that is one higher than the current block height:

[2023-03-05T18:48:29Z INFO  ord::index::updater] Committing at block height 779475, 0 outputs traversed, 0 in map, 0 cached
...
$ bitcoin-cli getblockcount
779474

And this seems potentially correlated with the frequent, intermittent:

error: JSON-RPC error: transport error: HTTP response too short: length 0, needed 12.

I've seen seeing with a lot of wallet operations.

I notice that this line of code in the Updater: https://github.com/casey/ord/blob/master/src/index/updater.rs#L51 is adding 1 to the value pulled from the db - is it possible that this is an off-by-one error?

[gmart7t2]

The root problem is with getblockcount itself.

What if there were just 3 blocks (0, 1, 2).

The block count is 3 but the biggest block number is 2.

The documentation for getblockcount says that it returns "The current block count" (ie. 3 in my example) but it doesn't. It returns the highest block number in the chain (2 in my example).

We see the same problem with the --limit-height flag in ord. If you use --limit-height 3 you might expect it to index up to block 3, but it only indexes up to block 2 (when the block count is 3, but the getblockcount is only 2).