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(block_production): Add tests to block_production_task method #478

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

GMKrieger
Copy link

Pull Request type

Please add the labels corresponding to the type of changes your PR introduces:

  • Testing

What is the current behavior?

Resolves: #NA

The block production tests currently only test block sealing when starting a new service.

What is the new behavior?

This PR aims to add tests on the block_production_task method and related methods to thoroughly test the code.

Does this introduce a breaking change?

No.

Other information

The testing format is based on #468. All feedback is welcome!

@GMKrieger GMKrieger added the testing Related to tests and test infrastructure label Jan 24, 2025
@GMKrieger GMKrieger self-assigned this Jan 24, 2025
@GMKrieger GMKrieger force-pushed the test/block-production-tests branch 3 times, most recently from 6b9d8ec to da627d1 Compare January 30, 2025 20:48
@GMKrieger GMKrieger marked this pull request as ready for review January 30, 2025 20:48
@GMKrieger GMKrieger force-pushed the test/block-production-tests branch 3 times, most recently from 4b05607 to 695e7de Compare February 5, 2025 19:18
Copy link
Collaborator

@Trantorian1 Trantorian1 left a comment

Choose a reason for hiding this comment

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

Left a few nitpicks, otherwise all seems good.

@GMKrieger GMKrieger force-pushed the test/block-production-tests branch 2 times, most recently from 1d2c093 to 3a371cf Compare February 10, 2025 16:03
@Trantorian1
Copy link
Collaborator

Trantorian1 commented Feb 14, 2025

@GMKrieger Could you please avoid force-pushing changes to a PR after a review has occurred? This makes it harder to review new changes since github cannot display "changes since last review".

Copy link
Collaborator

@Trantorian1 Trantorian1 left a comment

Choose a reason for hiding this comment

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

All good!

@GMKrieger GMKrieger force-pushed the test/block-production-tests branch from 3a371cf to 07e515d Compare February 14, 2025 12:55
Copy link

@HermanObst HermanObst left a comment

Choose a reason for hiding this comment

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

Hey @GMKrieger great job here!
In genreal I really like these test. I ask some changes. I general I would like to be more thorough on checking the state (empty, num txs) of:

  • mempool
  • pending block
  • latest block

Comment on lines +2095 to +2110
// keeps a consistent state
backend
.store_block(
mp_block::MadaraMaybePendingBlock {
info: mp_block::MadaraMaybePendingBlockInfo::Pending(mp_block::MadaraPendingBlockInfo {
header: mp_block::header::PendingHeader::default(),
tx_hashes: vec![Felt::ONE, Felt::TWO, Felt::THREE],
}),
inner: pending_inner.clone(),
},
pending_state_diff.clone(),
converted_classes.clone(),
Some(visited_segments.clone()),
Some(bouncer_weights),
)
.expect("Failed to store pending block");

Choose a reason for hiding this comment

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

What happen with this PendingBlock that we are storing? What should be the expected behavior.
Are we testing something that can even occur?

cc @Trantorian1 @GMKrieger

Copy link
Author

Choose a reason for hiding this comment

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

This pending block is overwriting the previous pending block, which is not the one the task is working on. Now the database has an inconsistent state.

The BlockProductionTask struct has the block it's working on an variable called block inside itself. This is the value we should work on and insert back on the database when finished.

This test currently tests a very edge case, let's say, someone tries to insert a pending block directly on the database and the block production task needs to keep working on the correct block.

But it's important to have a test like this because if there are future changes on the code that break this rule, this test will fail and warn the developer that something is off.

// have no transactions on it after the method ran for at
// least block_time

let result = block_production_task.on_block_time().await.expect_err("This should fail");

Choose a reason for hiding this comment

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

Out of curiosity, what happens if this situation is reach?
Is there some recovery?
cc/ @Trantorian1 @GMKrieger

Copy link
Author

Choose a reason for hiding this comment

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

Not that I know of. It just fails and quits.

Comment on lines 2598 to 2602
let pending_block: mp_block::MadaraMaybePendingBlock = backend.get_block(&DbBlockId::Pending).unwrap().unwrap();

assert!(mempool.is_empty());
assert!(pending_block.inner.transactions.is_empty());
}

Choose a reason for hiding this comment

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

Check what happened with the tx?

Comment on lines +2701 to +2705

assert!(mempool.is_empty());
assert!(pending_block.inner.transactions.is_empty());
assert_eq!(backend.get_latest_block_n().unwrap().unwrap(), 2);
}

Choose a reason for hiding this comment

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

Would be better to only add 1 tx just to have a difference within the previous one

Also check for the latest block number

Copy link
Author

Choose a reason for hiding this comment

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

Removed the extra tx, but I check the latest block number with assert_eq!(backend.get_latest_block_n().unwrap().unwrap(), 2);

Copy link

@HermanObst HermanObst left a comment

Choose a reason for hiding this comment

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

Good job!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
testing Related to tests and test infrastructure
Projects
Status: In review
Development

Successfully merging this pull request may close these issues.

None yet

3 participants