rpc: report index sync progress in getindexinfo #36296

arejula27 commented at 4:19 PM on September 18, 2026: contributor

getindexinfo reports synced and best_block_height, but not how far along an index actually is. To know it today, you either subtract best_block_height from getblockcount, which gives the number of blocks left rather than the number of transactions left (what the other RPCs use to report progress), or you work out the remaining transactions with four extra calls: getblockhash plus getchaintxstats, for both the index's best block and the chain tip.

This adds a progress field per index, computed like verificationprogress in getchainstates: a ratio of cumulative transactions, measured against this node's validated chain tip.

Two things I left open. I considered renaming best_block_height to blocks to match getchainstates, but that would break existing callers, so I didnt do it. And I did not find a way to hold an index at a known height, so the tests only cover the fully synced case. Input welcome on both.

DrahtBot added the label RPC/REST/ZMQ on Sep 18, 2026

DrahtBot commented at 4:19 PM on September 18, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/36296.

Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

sedited commented at 5:03 PM on September 18, 2026: contributor

Concept~0

Is there a consumer of the index asking for this? As you lay out, it is trivial to calculate the progress yourself, so not sure this really provides value.

DrahtBot added the label CI failed on Sep 18, 2026

DrahtBot commented at 5:22 PM on September 18, 2026: contributor

🚧 At least one of the CI tasks failed. <sub>Task iwyu: https://github.com/bitcoin/bitcoin/actions/runs/35367764129/job/105674240620</sub> <sub>LLM reason (✨ experimental): CI failed because IWYU detected missing/incorrect #includes (requiring edits to src/rpc/node.cpp, triggering an IWYU “Failure generated from IWYU”).</sub>

<details><summary>Hints</summary>

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

</details>

arejula27 commented at 5:37 PM on September 18, 2026: contributor

Thanks for taking a look!! I understand that this PR does not add a new feature, just a small UX improvement.

The motivation is my own experience (I am not aware of another user asking for it, but i think it will be useful). I have spent the last few months working with the indexes and waiting for them to reindex, and I do that from the GUI, not the CLI. The GUI shows nothing about indexes (which is something i would like to improve on the future). The only way to check is the debug console, and it cannot do arithmetic, so "calculate it yourself" means running getindexinfo, then getblockcount, and then subtracting and dividing on the PC calculator every time I want to look, it is not hard, but it is inconvinient.

Today the only value I get with getindexinfo is the indexed block height. It helps a bit, but transactions are not spread evenly across blocks, so the difference in heights is a bad estimate of the remaining time, which is what I want to know while waiting.

I fully understand your objection but, what made me open the PR is that the same field already exists in getchainstates, where the value can also be obtained with several calls. I could not find a reason why it makes sense there and not here, so I thought it was worth adding here too.

rpc: report index sync progress in getindexinfo cfbc202167

arejula27 force-pushed on Sep 18, 2026

bitcoin deleted a comment on Sep 18, 2026

in src/rpc/node.cpp:403 in cfbc202167

 399 | @@ -384,6 +400,7 @@ static RPCMethod getindexinfo()
 400 |                              {
 401 |                                  {RPCResult::Type::BOOL, "synced", "Whether the index is synced or not"},
 402 |                                  {RPCResult::Type::NUM, "best_block_height", "The block height to which the index is synced"},
 403 | +                                {RPCResult::Type::NUM, "progress", "Fraction of the validated chain the index covers [0..1]"},

fjahr commented at 8:24 PM on September 18, 2026:

It is redundant to calculate this when the index is already synced so it should be an optional result and skipped when the index is synced.

in src/rpc/node.cpp:365 in cfbc202167

 360 | @@ -357,14 +361,26 @@ static RPCMethod echoipc()
 361 |      };
 362 |  }
 363 |  
 364 | -static UniValue SummaryToJSON(const IndexSummary&& summary, std::string index_name)
 365 | +//! Fraction of the chain up to tip that the index covers, in cumulative transactions.
 366 | +static double IndexProgress(ChainstateManager& chainman, const CBlockIndex* tip, const IndexSummary& summary)

fjahr commented at 8:25 PM on September 18, 2026:

This code should probably go into the Index Summary code rather than here

in src/rpc/node.cpp:371 in cfbc202167

 367 | +    EXCLUSIVE_LOCKS_REQUIRED(::cs_main)
 368 | +{
 369 | +    AssertLockHeld(::cs_main);
 370 | +    const CBlockIndex* best{chainman.m_blockman.LookupBlockIndex(summary.best_block_hash)};
 371 | +    if (!best || !tip || best->m_chain_tx_count == 0 || tip->m_chain_tx_count == 0) return 0.0;
 372 | +    return std::min<double>(double(best->m_chain_tx_count) / double(tip->m_chain_tx_count), 1.0);

fjahr commented at 8:27 PM on September 18, 2026:

I don't know why the min would be needed here. Seems like the result should always be <= 1.0, if it is not an Assert would be more appropriate since something seems to be going pretty wrong.

fjahr commented at 8:32 PM on September 18, 2026: contributor

Concept -0

I don't really believe that this is useful to enough users to justify adding it. I can imagine that typical GUI users may be interested in seeing a progress bar that they can look at while they wait. But from an RPC consumer I would expect they either just want to start using the index when it's fully ready, so they would periodically check for synced or in some rarer cases where the index becomes useful to them before a full sync they would probably check the best_block_height to know when they can start using it. The progress number is really an RPC replacement for the GUI visual progress bar, which is how you describe your usage as well, but I don't think that this is something RPC consumers would have use for. It does have some maintenance and performance impact, so I would rather keep it out. Nonetheless, I couldn't help myself and left some approach feedback, maybe it will be useful learning you can apply in some different context but even if you still address it that won't change my judgement.

arejula27 commented at 9:06 PM on September 18, 2026: contributor

Thanks both for ur feedback! Totally agree that this change is just a (worse) substitute for a progress bar on the GUI. As right know thre is a ongoing migration process for a new GUI i will wait it until the new one is merged.

Closing this PR to not waste more reviewers time

arejula27 closed this on Sep 18, 2026