Skip to content

Fix client monitoring rate limit errors - #5189

Merged
wemeetagain merged 1 commit into
ChainSafe:unstablefrom
nflaig:fix-monitoring-rate-limit-errors
Feb 21, 2023
Merged

Fix client monitoring rate limit errors#5189
wemeetagain merged 1 commit into
ChainSafe:unstablefrom
nflaig:fix-monitoring-rate-limit-errors

Conversation

@nflaig

@nflaig nflaig commented Feb 21, 2023

Copy link
Copy Markdown
Member

Motivation

Follow up change for #5037 which fixes beaconcha.in rate limit errors.

Description

The current implementation might send the next request too early if the previous one took a bit longer due to the nature of how setInterval works, it does not wait for async functions to finish.

This change ensure we are only starting the next interval after the previous request has finished.

Reverts changes done in this commit as setting interval to 62 seconds did not actually fix the issue just made it less likely to happen.

We can safely set the interval to 60 seconds now as we will only start the next interval after we the get previous response which means the sent interval might vary a bit (usually just a few milliseconds) depending on the response times of the remote service.

@nflaig
nflaig requested a review from a team as a code owner February 21, 2023 11:05
Ensure next interval only starts after previous request has finished
else we might send next request too early and run into rate limit errors.
@nflaig
nflaig force-pushed the fix-monitoring-rate-limit-errors branch from a809022 to c2fba44 Compare February 21, 2023 11:18
}

private nextMonitoringInterval(): void {
if (this.status === Status.Stopped) return;

@nflaig nflaig Feb 21, 2023

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This check just prevents an edge case which can happen due to a race condition where this.send() has not yet finished but service was stopped, it would invoke this.nextMonitoringInterval() again and keep the interval running even though service is already stopped.

This is probably never relevant if the BN or VC run as standalone services because the whole process will be stopped either way but if it is embedded in another software this might matter.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Just noting here that this change is also quite important if BN or VC are standalone services as setting another timeout would prevent the process from exiting

@philknows philknows added this to the v1.5.0 milestone Feb 21, 2023
@wemeetagain
wemeetagain merged commit a17701a into ChainSafe:unstable Feb 21, 2023
@nflaig nflaig modified the milestones: v1.5.0, v1.6.0 Mar 4, 2023
@wemeetagain

Copy link
Copy Markdown
Member

馃帀 This PR is included in v1.6.0 馃帀

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