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

eth/executionclient: rate limit multi client Healthy call #2010

Merged
merged 3 commits into from
Feb 3, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion eth/executionclient/defaults.go
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ const (
DefaultConnectionTimeout = 10 * time.Second
DefaultReconnectionInitialInterval = 1 * time.Second
DefaultReconnectionMaxInterval = 64 * time.Second
DefaultHealthInvalidationInterval = 10 * time.Second // TODO: decide on this value, for now choosing a bit less than block interval
DefaultHealthInvalidationInterval = 24 * time.Second // TODO: decide on this value, for now choosing the node prober interval but it should probably be a bit less than block interval
DefaultFollowDistance = 8
// TODO ALAN: revert
DefaultHistoricalLogsBatchSize = 500
Expand Down
6 changes: 6 additions & 0 deletions eth/executionclient/multi_client.go
Original file line number Diff line number Diff line change
Expand Up @@ -71,6 +71,7 @@
clientsMu []sync.Mutex // clientsMu allow for lazy initialization of each client in `clients` slice in thread-safe manner (atomically)
clients []SingleClientProvider // nil if not connected
currentClientIndex atomic.Int64
lastHealthy atomic.Int64
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe lastHealthy -> lastHealthyTimestamp (or lastHealthyTsUnix)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

IMO both are fine,Timestamp and TsUnix indicate what kind of data is stored, but when time is stored as an int, it's common that it's a timestamp

Copy link
Contributor

@iurii-ssv iurii-ssv Feb 3, 2025

Choose a reason for hiding this comment

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

I mean, it could mean slot number for all I know (without looking up how it's used) - but since it's minor implementation detail it's no big deal

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, I agree, I didn't think about the slot. Well, if it causes any confusion, let's rename it in the future

}

// NewMulti creates a new instance of MultiClient.
Expand Down Expand Up @@ -278,6 +279,10 @@

// Healthy returns if execution client is currently healthy: responds to requests and not in the syncing state.
func (mc *MultiClient) Healthy(ctx context.Context) error {
if time.Since(time.Unix(mc.lastHealthy.Load(), 0)) < mc.healthInvalidationInterval {
return nil
}

Check warning on line 284 in eth/executionclient/multi_client.go

View check run for this annotation

Codecov / codecov/patch

eth/executionclient/multi_client.go#L283-L284

Added lines #L283 - L284 were not covered by tests

healthyClients := atomic.Bool{}
p := pool.New().WithErrors().WithContext(ctx)

Expand Down Expand Up @@ -307,6 +312,7 @@
}
err := p.Wait()
if healthyClients.Load() {
mc.lastHealthy.Store(time.Now().Unix())
return nil
}
return fmt.Errorf("no healthy clients: %w", err)
Expand Down