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 when starting fast sync, forked #1290
Conversation
@@ -720,6 +721,10 @@ def validate_uncles(self, block: BaseBlock) -> None: | |||
""" | |||
Validate the uncles for the given block. | |||
""" | |||
if block.header.uncles_hash == EMPTY_UNCLE_HASH and len(block.uncles) == 0: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you get back in here, you might expand this to:
has_uncles = len(block.uncles) > 0
should_have_uncles = block.header.uncles_hash != EMPTY_UNCLE_HASH
if not has_uncles and not should_have_uncles:
return #otpimization
elif has_uncles and not should_have_uncles:
raise ValidationError("Block has uncles but header suggests uncles should be empty")
elif should_have_uncles and not has_uncles:
raise ValidationError("Header suggests block should have uncles but block has no uncles")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do in a follow-up
@@ -220,7 +220,7 @@ def call_later(self, delay: float, callback: 'Callable[..., None]', *args: Any) | |||
|
|||
@functools.wraps(callback) | |||
async def _call_later_wrapped() -> None: | |||
self.sleep(delay) | |||
await self.sleep(delay) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😮
What was wrong?
When running fast sync, it might start on a fork from the end of the last sync. This was causing a crash.
Other similar problems are currently possible (but shouldn't be for long), like starting later than the canonical head, because headers were saved into an inconsistent state.
How was it fixed?
Catch the
ValidationError
when trying to register the block/receipt download tasks. Confirm that the parent header already exists (which the common sync should have already done). Then allow the sync to continue, with a log.This required a change in
OrderedTaskPreparation
: it can now accept multiple "already finished" tasks.Some other bonus fixes:
Cute Animal Picture