Feature Request

We got feedback from multiple users that the application might have specific logic that is not supposed to run in case the node is not in sync with the rest of the network.

Summary

Problem Definition

What problems may be addressed by introducing this feature?
What benefits does CometBFT stand to gain by including this feature?

User feedback:

I need to know if the blockchain is doing a block sync or not. Because when syncing, there is some application logic that I don't need to execute.
How can I know if the consensus engine is synchronizing or not?
Before [in v0.36] I did app.Service.(*node.Node).ConsensusReactor().WaitSync(). I'm not sure what would be ideal. For now, I'm just missing the ConsensusReactor access. So I can check if the blockchain is still syncing or not.

For ref. on the above discussion, we had trimmed the Go API surface in v0.38 to remove accessor to ConsensusReactor. Since a user highlighted they are using this API, we reverted that change in v0.38 RC3.

we have a similar use case
basically there is some node-local logic (e.g. not part of consensus itself) which needs to know whether the node is syncing or not as it doesn't make sense to run it during sync

is there a way for the application to know that cometbft is currently replaying blocks and not at the head of the chain taking part of conssensus with the other nodes?
Every of our validator nodes are sourcing log events from ethereum to find deposits [for example]. And when doing this, sending an event on our chain, from there all nodes are also starting procedure to verify the event really happen on ethereum, from there if they can confirm it, they will send a vote on our chain, and when 2/3 of the validator vote for a deposit, an account on our chain is credited. Now the issue is that when replaying, the node will be emitting event / votes for things which have been acknowledge by our chain for a while. So while it is not a big deal in term of consistency as the chain/app protects against using transaction twice, it's a bit of an issue as the node end up filling their mempool with lots of event which are far in the past, and unnecessary, but also increase the processing.

For ref on this discussion, it seems like #785 is a potential fix.

Proposal

Adjust the FinalizeBlock call to add height of tip of chain.