feat(net): improve chain inventory generating logic by jwrct · Pull Request #5393

feat(net): improve chain inventory generating logic by jwrct · Pull Request #5393 · tronprotocol/java-tron

What does this PR do?
Retrying inventory generating if first blockId does not match the chain summary.

Why are these changes required?

This PR has been tested by:

Unit Tests
Manual Testing

Follow up

Extra details

jwrct linked an issue

Aug 2, 2023

that may be closed by this pull request

jwrct changed the title ~~feat(net):improve chain inventory generating logic~~ feat(net): improve chain inventory generating logic

Aug 2, 2023

		LinkedList<BlockId> ids = getBlockIds(unForkId.getNum());

		if (ids.isEmpty() \|\| !unForkId.equals(ids.peekFirst())) {
		unForkId = getUnForkId(blockIds);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm not mistaken, is it just a retry?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it can be solved by retrying.

		boolean f = (boolean)method.invoke(handler, peer, message);
		Assert.assertTrue(!f);

		Method method1 = handler.getClass().getDeclaredMethod(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to reproduce this scenario without using reflection?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, further optimization.

It only happened with the forks which are not finalized?

If so, all the blocks on both(or more) forks are stored in memory?

If all the above is right, just sending the corresponding blocks can solve this thoroughly?

It only happened with the forks which are not finalized?

yes

If so, all the blocks on both(or more) forks are stored in memory?

This problem will only involve non-solidified blocks.

If all the above is right, just sending the corresponding blocks can solve this thoroughly?

After the chain switch is completed, the generated inventory is without any problems.

After the chain switch is completed, the generated inventory is without any problems.

I mean generating the inventory by iterating the specified fork instead of using tronNetDelegate.getBlockIdByNum(i) may solve this thoroughly, but seems an interface for querying the fork chain doesn't exist.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved, @wubin01 should do a double check

		@@ -87,6 +87,18 @@ private boolean check(PeerConnection peer, SyncBlockChainMessage msg) throws P2p

		private LinkedList<BlockId> getLostBlockIds(List<BlockId> blockIds) throws P2pException {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.