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

harden ethmonitor for block header streaming errors #118

Merged
merged 6 commits into from
Apr 15, 2024

Conversation

marino39
Copy link
Contributor

@marino39 marino39 commented Apr 12, 2024

  1. The change switches ethmonitor from head streaming to poll if it encounters too many errors in a row.
  2. The ethmonitor will restart the head streaming if block heads are not published in a timely manner.
  3. The ethmonitor if in head poll mode will try to go back to head stream mode after specified time.

The change can be tested by setting up local nodegateway, pointing watch cmd at it and stoping/restarting node gateway service.

@marino39 marino39 marked this pull request as ready for review April 15, 2024 08:29
@marino39 marino39 requested a review from pkieltyka April 15, 2024 08:30
@pkieltyka pkieltyka merged commit b69b303 into master Apr 15, 2024
4 checks passed
@pkieltyka pkieltyka deleted the harden-ethmonitor-streaming branch April 15, 2024 19:15
Copy link
Contributor

@VojtechVitek VojtechVitek left a comment

Choose a reason for hiding this comment

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

LGTM. Nice work here @marino39

// We default to polling if streaming is not enabled
m.log.Info("ethmonitor: starting poll head listener")

retryStreamingTimer := time.NewTimer(m.options.StreamingRetryAfter)
Copy link
Contributor

Choose a reason for hiding this comment

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

defer retryStreamingTimer.Stop()

goto reconnect
}

blockTimer := time.NewTimer(3 * m.options.ExpectedBlockInterval)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: defer blockTimer.Stop()

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Resource leak, agrh... defer will not help as it never goes out of function scope. I will get that fixed asap.

Copy link
Member

Choose a reason for hiding this comment

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

#119 -- hows this..?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, it is good. The timer will close itself after it fires and will be garbage collected. So there is no need to close it. It will also not cause process to hang. There will be at most a couple of them.

// After waits for the duration to elapse and then sends the current time
// on the returned channel.
// It is equivalent to NewTimer(d).C.
// The underlying Timer is not recovered by the garbage collector
// until the timer fires. If efficiency is a concern, use NewTimer
// instead and call Timer.Stop if the timer is no longer needed.
func After(d Duration) <-chan Time {
	return NewTimer(d).C
}

Copy link
Contributor

Choose a reason for hiding this comment

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

“a little temporary timer leak” is fine imho

it’d probably be better to close it, though, to be accurate
(a leaked timeout might cause an unnecessary OS interrupt)

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