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

Conversation

nkryuchkov
Copy link
Contributor

No limit overloads the node

Copy link

codecov bot commented Feb 3, 2025

Codecov Report

Attention: Patch coverage is 25.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 48.0%. Comparing base (285cd60) to head (c397d56).
Report is 1 commits behind head on stage.

Files with missing lines Patch % Lines
eth/executionclient/multi_client.go 25.0% 2 Missing and 1 partial ⚠️
Additional details and impacted files

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@nkryuchkov nkryuchkov requested a review from moshe-blox February 3, 2025 13:37
@nkryuchkov nkryuchkov changed the title eth/executionclient: rate limit Healthy call eth/executionclient: rate limit multi client Healthy call Feb 3, 2025
Copy link
Contributor

@iurii-ssv iurii-ssv left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -71,6 +71,7 @@ type MultiClient struct {
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

@y0sher y0sher merged commit 30c677f into stage Feb 3, 2025
6 of 7 checks passed
@y0sher y0sher deleted the el-healthy-rate-limit branch February 3, 2025 14:03
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