-
Notifications
You must be signed in to change notification settings - Fork 19
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
Retry fetch logs #317
Retry fetch logs #317
Conversation
5cffb2e
I also added a goreleaser change to not mark rc's as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just a suggestion about using an exponential back off if the height difference can be significant.
return logs, nil | ||
} | ||
if i != numRetries-1 { | ||
time.Sleep(retryInterval) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to consider some type of exponential back off between retries if the height difference between nodes can potentially be significant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As part of the nonce ordering fix, I'm going to implement a generic retry helper, and will consider adding exponential backoffs there.
Why this should be merged
The websocket connection serving new blocks to process and the RPC request to fetch logs from a block containing Warp messages may be served by different nodes that have indexed different heights. If the node serving the RPC request is behind the node serving blocks, then the
FilterLogs
call will fail. Adding retries the theFilterLogs
RPC request works around this.How this works
See above
How this was tested
CI
How is this documented
N/A