-
Notifications
You must be signed in to change notification settings - Fork 886
Event-based block lookup tests #5534
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
Conversation
…e extra beacon chain harness instance created in tests.
|
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.
Love the move to event based testing, thanks @jimmygchen and @dapplion !
The test do already look more straightforward and looks like there are some logging improvements in here.
stateless vs. builder-ish API
This PR is worth merging regardless of where we land there.
Any sync tests are quite difficult to understand for those that have not written them. Having comments explaining the case is very important for either style. In that direction I think we should focus much more on having the test easy to understand and well documented with comments besides succintness
Agree! My fault for lack of comments on a lot of the existing ones.
} | ||
|
||
fn after_deneb(&self) -> bool { | ||
matches!(self.current_fork(), ForkName::Deneb | ForkName::Electra) |
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.
Here's a place fork order would be useful, so we don't forget to enable these in future forks
range_sync: RangeSync::new(beacon_chain.clone(), log.clone()), | ||
backfill_sync: BackFillSync::new(beacon_chain.clone(), network_globals, log.clone()), | ||
block_lookups: BlockLookups::new( | ||
beacon_chain.data_availability_checker.clone(), | ||
log.clone(), | ||
), |
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.
Unrelated to this PR but since you're touching this I thought it might be worth mentioning - perhaps we could create child logger for each of these individual components so we know where the log is coming from?
log.new(slog::o!("service" => "range_sync")
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.
ps. i'm not suggesting a change in this PR
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.
Does this label then apply to all logs? That's a good suggestion, can add to a future PR def
Moved the logging changes into their own PR |
rng: XorShiftRng, | ||
harness: BeaconChainHarness<T>, | ||
sync_manager: SyncManager<T>, | ||
beacon_processor: Arc<NetworkBeaconProcessor<T>>, |
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.
Any reasons to have beacon_processor
in the TestRig
? I don't see it being used other than accessing network_globals
.
I kept it out because the test rig should not need to directly interact with the beacon_processor
directly in any way, otherwise it could interfere testing of the SyncManager
.
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.
Good point! Removed beacon_processor for network_globals, and harness for fork_name
rng: XorShiftRng, | ||
harness: BeaconChainHarness<T>, | ||
sync_manager: SyncManager<T>, | ||
beacon_processor: Arc<NetworkBeaconProcessor<T>>, |
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.
Could we have some of the field documentation back as I think it would help people writing the tests understand what each of these fields are for, without reading through the implementation.
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.
Added!
@Mergifyio queue |
🛑 The pull request rule doesn't match anymoreThe pull request has been synchronized by a user. |
@Mergifyio refresh |
✅ Pull request refreshed |
@Mergifyio requeue |
✅ This pull request will be re-embarked automaticallyThe followup |
🛑 The pull request has been removed from the queue
|
@mergify requeue |
✅ This pull request will be re-embarked automaticallyThe followup |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at b1f9751 |
Issue Addressed
Extends @jimmygchen refactor by
This PR does not:
Switching to event-based tests is very valuable to generalize tests, allow to test more diverse edge cases, and allow refactors without being too tied to block lookup internals.
This PR is an alternative to
SyncTester
#5530Proposed Changes
All tests now interface with sync through this event channels
Additional Info
RE: style we can discuss as follow-up to this PR, I see as the contentious options:
Some notes to inform the above:
chained API doesn't play well with backtrace
Consider this code, and a panic in action_a
The backtrace line for
action_a
will declare line 10. You can't know which of the two action_a invocations caused the errorinternal implicit state succinctness
Post-deneb test are shorter at the expense of clarity. There's machinery in the back that makes assumptions about what request is doing what. For straightforward cases it's fine but it can be restrictive for more complex cases. Pre-deneb tests with proper helper functions should look as succint as those with a chained API. We can remane
rig
tor
and it almost looks like chained, which allowing conditional flow and storing variables.Comments
Any sync tests are quite difficult to understand for those that have not written them. Having comments explaining the case is very important for either style. In that direction I think we should focus much more on having the test easy to understand and well documented with comments besides succintness