Jormungandr: blockRecvCnt is often higher than lastBlockHeight

[mark-stopka]

Describe the bug
blockRecvCnt is often higher than lastBlockHeight, I assume it's because the node was processing blocks from the fork chain, but I would expect this to be clearly reported in a better manner.

blockRecvCnt: 14589
lastBlockDate: "30.3783"
lastBlockFees: 0
lastBlockHash: cb831b207e4cb17f35ca2d7bdcbd2336bdacc2efbb871d236b89232a8a5423d8
lastBlockHeight: "13204"
lastBlockSum: 0
lastBlockTime: "2019-10-29T17:32:42+00:00"
lastBlockTx: 0
state: Running
txRecvCnt: 0
uptime: 1487

Mandatory Information

1. jcli --full-version output;

./jcli --full-version
jcli 0.7.0-rc1 (HEAD-5583e5e, release, linux [x86_64]) - [rustc 1.38.0 (625451e37 2019-09-23)]

1. jormungandr --full-version output;

./jormungandr --full-version
jormungandr 0.7.0-rc1 (HEAD-5583e5e, release, linux [x86_64]) - [rustc 1.38.0 (625451e37 2019-09-23)]

To Reproduce
Steps to reproduce the behavior:

1. Start a node and let it run

[NicolasDP]

How is that a bug?

EDIT: came out the wrong way, what would you do instead?

[mark-stopka]

@NicolasDP, would it be possible to have three values like this?

• Total blocks processed
• Total blocks processed on current chain (current being the chain we believe not to be a fork)
• Amount of discarded blocks?

I understand this is not exactly a bug, but rather a UX issue / inconvenience; it's making troubleshooting jointly with members of the Telegram group more difficult.

[Chris-Graffagnino]

Folks are troubleshooting why they haven't received funds from the faucet, despite receiving a "success" response. In the case of a new node, the assumption is that the block containing the transaction hasn't reached their node. This assumption seems to be contradicted when blockRecvCnt is higher than lastBlockHeight.

Perhaps it would be helpful to add a boolean indicating the node is up to date with the rest of the network.