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

Live sync transition scenario tests #10015

Closed
Tracked by #8742 ...
mattsse opened this issue Aug 2, 2024 · 0 comments · Fixed by #10154
Closed
Tracked by #8742 ...

Live sync transition scenario tests #10015

mattsse opened this issue Aug 2, 2024 · 0 comments · Fixed by #10154
Assignees
Labels
C-bug An unexpected or incorrect behavior C-test A change that impacts how or what we test

Comments

@mattsse
Copy link
Collaborator

mattsse commented Aug 2, 2024

transitioning to live sync after backfill sync of when the node started is tricky and involves a few things

  1. we need to find out the height of the chain, and check how far we're off
  2. if we're close to the tip we either need to download missing blocks to catch up or trigger pipeline sync
    const fn exceeds_backfill_run_threshold(&self, local_tip: u64, block: u64) -> bool {
  3. then we need to download blocks and execute them, if we eventually have the canonical head, we can make all executed blocks canonical:
    if self.is_sync_target_head(block_num_hash.hash) {
    // we just inserted the current sync target block, we can try to make it
    // canonical
    return Some(TreeEvent::TreeAction(TreeAction::MakeCanonical(
    block_num_hash.hash,
    )))
    }

TODO

we need to cover a few scenarios here that ensure we are able to catch up with the tip:

  1. tree requests the appropriate blocks,
  2. tree is able to close the gap with downloaded blocks and will always reach canonical state eventually
  3. tree is able to trigger backfill if it realises it is too far behind from tip

I believe the way we currently pick the download target is a bit buggy because this only checks the buffered blocks but we could have this target already executed

let target = self.lowest_buffered_ancestor_or(target);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug An unexpected or incorrect behavior C-test A change that impacts how or what we test
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants