Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: fix new block handling of non-tip blocks #4431

Merged

Conversation

SWvheerden
Copy link
Collaborator

@SWvheerden SWvheerden commented Aug 10, 2022

Description

Currently, the base node cannot process a block that was received out of order (aka orphaned).
The reconcile_block function makes the assumption that the block is always on the current tip and tries to calculate the MMR roots of the block as a sanity check. The MMR roots can only be checked by a block that is built on the current local tip.
This changes the reconcile_block function to first check orphan status, and if true, it will require the full block from the peer.

This Pr also changes how the db lock is processed. Currently, it will print out a warn followed by an error. This suppresses the error and only prints the warn.

How Has This Been Tested?

Manual

Fixes: #4352

error!(target: LOG_TARGET, "Failed to handle incoming block message: {:?}", e);
match result {
Err(BaseNodeServiceError::CommsInterfaceError(CommsInterfaceError::ChainStorageError(
ChainStorageError::CannotAcquireFileLock,
Copy link
Member

Choose a reason for hiding this comment

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

This error only happens when you startup a node with the same base dir - the db lockfile is present.
Cannot acquire exclusive file lock, another instance of the application is already running

Which error message are you trying to suppress?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

good catch, wrong error.

@SWvheerden SWvheerden force-pushed the sw_fix_orphan_handling branch 2 times, most recently from 26c7cc9 to ded0584 Compare August 10, 2022 11:11
Copy link
Collaborator

@stringhandler stringhandler left a comment

Choose a reason for hiding this comment

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

I don't understand the need for this special case. Surely the mempool check will perform the same logic?

@stringhandler stringhandler changed the title fix: block orphan handling fix: fix new block handling of non-tip blocks Aug 10, 2022
@stringhandler stringhandler merged commit ee757df into tari-project:development Aug 10, 2022
@SWvheerden SWvheerden deleted the sw_fix_orphan_handling branch August 12, 2022 05:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Failed to handle incoming block
4 participants