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

Multiple BN HTTP resolver #13433

Merged
merged 48 commits into from
May 29, 2024
Merged

Multiple BN HTTP resolver #13433

merged 48 commits into from
May 29, 2024

Conversation

saolyn
Copy link
Contributor

@saolyn saolyn commented Jan 9, 2024

What type of PR is this?

Other

What does this PR do? Why is it needed?

This pull request aims to enhance the HTTP client to support multiple endpoints that the nodes can switch between when necessary.

The endpoints host:port will be specified through a flag. For instance, the flag could be set to "127.0.0.1:4000, 127.0.0.1:4001" to define two endpoints.

We are adding this as we have a similar setup for GRPC that we are going to eventually deprecate. And therefore require it for the HTTP client.

Other notes for review
Currently the number of files changed is massive as I had to regenerate gomock with another library, when this PR merges #13639 these should clear up.

@saolyn saolyn requested a review from rkapka February 21, 2024 19:05
@saolyn saolyn marked this pull request as ready for review February 21, 2024 19:05
@saolyn saolyn requested a review from a team as a code owner February 21, 2024 19:05
@@ -237,7 +239,7 @@ func (v *ValidatorService) Start() {
}

v.validator = valStruct
go run(v.ctx, v.validator)
go run(v.ctx, v.validator, hosts)
Copy link
Contributor

Choose a reason for hiding this comment

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

if there are get host and update host functions on the validator, what about just adding hosts to the validator client? instead of passing it down as arguments?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, this makes a lot of sense. Instead of updating the host in the goroutine, we can have an UpdateHost() function without arguments that updates the host internally.

}
go func() {
// deadline set for 1 epoch from call to not overlap.
epochDeadline := v.SlotDeadline(slot + params.BeaconConfig().SlotsPerEpoch - 1)
Copy link
Contributor

Choose a reason for hiding this comment

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

this deadline needs to change as we don't have a check if it's epoch start so this deadline will be wrong. I think it might be better to just have a default value.

if url == v.RetrieveHost() {
next := (i + 1) % len(hosts)
log.Infof("Beacon node at %s is not responding, switching to %s", url, hosts[next])
v.UpdateHost(hosts[next])
Copy link
Contributor

Choose a reason for hiding this comment

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

don't you need to check health again after the host is updated and break until the next ticker if it is not healthy?


km, err := v.Keymanager()
if err != nil {
log.WithError(err).Fatal("Could not get keymanager")
Copy link
Contributor

Choose a reason for hiding this comment

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

something doesn't feel right here about logging a fatal, it's needed for the push proposer settings but not sure if the whole thing should break if it can't get the keymanager

Copy link
Contributor

Choose a reason for hiding this comment

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

I would say not being able to obtain the keymanager is very bad, but yeah maybe just log an error and return? Not 100% sure. This should realistically never happen anyway.

validator/client/service.go Outdated Show resolved Hide resolved
Copy link
Contributor Author

@saolyn saolyn left a comment

Choose a reason for hiding this comment

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

New changes LGTM, thanks!

@rkapka rkapka enabled auto-merge May 29, 2024 01:21
@rkapka rkapka added this pull request to the merge queue May 29, 2024
Merged via the queue into develop with commit 6fddd13 May 29, 2024
16 of 17 checks passed
@rkapka rkapka deleted the http-resolver branch May 29, 2024 01:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants