Skip to content

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

Merged
merged 17 commits into from
Apr 10, 2024
Merged

Event-based block lookup tests #5534

merged 17 commits into from
Apr 10, 2024

Conversation

dapplion
Copy link
Collaborator

@dapplion dapplion commented Apr 8, 2024

Issue Addressed

Extends @jimmygchen refactor by

  • Applying the changes to all existing block lookup tests
  • Injects events directly on handle_message to avoid async machinery :)

This PR does not:

  • Change the syntatic style of existing tests
  • Modify or extend the tested scenarios. However it adds helper functions to make them more succint

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

Proposed Changes

All tests now interface with sync through this event channels

                     +-----------------+
                     | BeaconProcessor |
                     +---------+-------+
                            ^  |
                            |  |
                  WorkEvent |  | SyncMsg
                            |  | (Result)
                            |  v
+--------+            +-----+-----------+             +----------------+
| Router +----------->|  SyncManager    +------------>| NetworkService |
+--------+  SyncMsg   +-----------------+ NetworkMsg  +----------------+
          (RPC resp)  |  - RangeSync    |  (RPC req)
                      +-----------------+
                      |  - BackFillSync |
                      +-----------------+
                      |  - BlockLookups |
                      +-----------------+

Additional Info

RE: style we can discuss as follow-up to this PR, I see as the contentious options:

  • Use declarative "state-less" API (pre-deneb tests)
  • Use a chained builder-stype API for tests with internal implicit state (post-deneb)

Some notes to inform the above:

chained API doesn't play well with backtrace

Consider this code, and a panic in action_a

10: rig
11:   .action_a()
12:   .action_b()
13:   .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 error

internal 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 to r 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

Copy link

mergify bot commented Apr 8, 2024

⚠️ The sha of the head commit of this PR conflicts with #5530. Mergify cannot evaluate rules on this PR. ⚠️

Copy link
Member

@realbigsean realbigsean left a 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)
Copy link
Member

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

Comment on lines +267 to +272
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(),
),
Copy link
Member

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")

Copy link
Member

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

Copy link
Collaborator Author

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

@dapplion
Copy link
Collaborator Author

dapplion commented Apr 9, 2024

Moved the logging changes into their own PR

rng: XorShiftRng,
harness: BeaconChainHarness<T>,
sync_manager: SyncManager<T>,
beacon_processor: Arc<NetworkBeaconProcessor<T>>,
Copy link
Member

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.

Copy link
Collaborator Author

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>>,
Copy link
Member

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.

https://github.com/sigp/lighthouse/pull/5530/files#diff-13439a1c05bab56ff7fb8b91e2d4f569076456e8a909000e1d9d3b5df8afb1b0R59-R81

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Added!

@realbigsean realbigsean added the ready-for-merge This PR is ready to merge. label Apr 9, 2024
@realbigsean
Copy link
Member

@Mergifyio queue

Copy link

mergify bot commented Apr 9, 2024

queue

🛑 The pull request rule doesn't match anymore

The pull request has been synchronized by a user.

mergify bot added a commit that referenced this pull request Apr 9, 2024
@realbigsean
Copy link
Member

@Mergifyio refresh

Copy link

mergify bot commented Apr 9, 2024

refresh

✅ Pull request refreshed

@realbigsean
Copy link
Member

@Mergifyio requeue

Copy link

mergify bot commented Apr 9, 2024

requeue

✅ This pull request will be re-embarked automatically

The followup queue command will be automatically executed to re-embark the pull request

Copy link

mergify bot commented Apr 9, 2024

queue

🛑 The pull request has been removed from the queue default

The queue conditions cannot be satisfied due to failing checks.

You can take a look at Queue: Embarked in merge queue check runs for more details.

In case of a failure due to a flaky test, you should first retrigger the CI.
Then, re-embark the pull request into the merge queue by posting the comment
@mergifyio refresh on the pull request.

@jimmygchen
Copy link
Member

@mergify requeue

Copy link

mergify bot commented Apr 10, 2024

requeue

✅ This pull request will be re-embarked automatically

The followup queue command will be automatically executed to re-embark the pull request

Copy link

mergify bot commented Apr 10, 2024

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at b1f9751

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-merge This PR is ready to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants