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

test: live sync test to check make canonical #10131

Merged
merged 7 commits into from
Aug 7, 2024

Conversation

fgimenez
Copy link
Member

@fgimenez fgimenez commented Aug 6, 2024

Towards: #10015

Adds a test to verify that the live synced blocks after a backfill sync are eventually made canonical.

These are the steps of the test

  • creates a chain with 10 more elements than required to trigger a backfill sync
  • issues a fcu request to an element of the chain that should trigger a backfill sync
  • once done, issues a fcu to the ti of the chain
  • verifies that the tip is made canonical.

To make it work I needed to call make_canonical in try_connect_buffered_blocks on successful insertion, otherwise, this was only done on the code path for downloaded blocks, pls let me know if this is advisable.

There's also additional refactors and improvements in TestHarness, like setting up the inserted headers in mock provider to properly simulate a persisted chain.

@fgimenez fgimenez added the C-test A change that impacts how or what we test label Aug 6, 2024
@fgimenez fgimenez force-pushed the fgimenez/live-sync-transition-reach-canonical branch from e9f015f to 65a9afe Compare August 6, 2024 15:57
@fgimenez fgimenez added the C-bug An unexpected or incorrect behavior label Aug 6, 2024
@fgimenez fgimenez changed the title test: extend live sync test to check make canonical test: live sync test to check make canonical Aug 6, 2024
@fgimenez fgimenez force-pushed the fgimenez/live-sync-transition-reach-canonical branch from 6fe0ab7 to 33a4a1a Compare August 6, 2024 19:30
@fgimenez fgimenez marked this pull request as ready for review August 6, 2024 19:30
Comment on lines 1322 to 1348
if self.is_sync_target_head(child_num_hash.hash) {
self.make_canonical(child_num_hash.hash);
}
Copy link
Member Author

Choose a reason for hiding this comment

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

this is the main change in the PR, without this the additional blocks after backfill sync were not being made canonical.

Copy link
Collaborator

Choose a reason for hiding this comment

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

oh very nice, yeah I actually noticed this and was wondering

}

self.provider.extend_blocks(block_data);
self.provider.extend_headers(headers_data);
Copy link
Member Author

Choose a reason for hiding this comment

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

this allows us to properly query the provider for data persisted.

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

awesome find, love the tests that make it obvious what scenario is being tested.

I have one suggestion re when we actually call make_canonical on insert

Comment on lines 1322 to 1348
if self.is_sync_target_head(child_num_hash.hash) {
self.make_canonical(child_num_hash.hash);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

oh very nice, yeah I actually noticed this and was wondering

Comment on lines 1322 to 1348
if self.is_sync_target_head(child_num_hash.hash) {
self.make_canonical(child_num_hash.hash);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

this makes perfect sense, but I think we should add an additional check here that ensures, this is a new block by checking the InsertPayloadOk

/// The payload was valid and inserted into the tree.
Inserted(BlockStatus),

separately, we should consider not reusing this from legacy tree but roll our own that no longer needs the BlockAttachment

Copy link
Member Author

Choose a reason for hiding this comment

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

this makes perfect sense, but I think we should add an additional check here that ensures, this is a new block by checking the InsertPayloadOk

makes sense, done here b5b1b34

separately, we should consider not reusing this from legacy tree but roll our own that no longer needs the BlockAttachment

sure I can work on this in a follow-up

@fgimenez fgimenez force-pushed the fgimenez/live-sync-transition-reach-canonical branch from 0173725 to b5b1b34 Compare August 7, 2024 07:41
@mattsse mattsse added this pull request to the merge queue Aug 7, 2024
Merged via the queue into main with commit e7214af Aug 7, 2024
34 checks passed
@mattsse mattsse deleted the fgimenez/live-sync-transition-reach-canonical branch August 7, 2024 10:08
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
None yet
Development

Successfully merging this pull request may close these issues.

2 participants