-
Notifications
You must be signed in to change notification settings - Fork 391
fix(operator): manage subscription to events without panic #1729
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
fix(operator): manage subscription to events without panic #1729
Conversation
uri-99
left a comment
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.
biased self-approve
…o-events-without-panic
JuArce
left a comment
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.
The same comments apply for V3
…o-events-without-panic
…o-events-without-panic
Changes to gas cost
🧾 Summary (10% most significant diffs)
Full diff report 👇
|
MarcosNicolau
left a comment
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.
Worked for me. I've updated the how-to-test section in the pr description to use ethereum-package. Not related to this pr I noticed that when deactivating the fallback of the Batcher, the Batcher stops listening to blocks, thus not creating new batches.
Co-authored-by: Marcos Nicolau <[email protected]>
Manage Operator's event subscription
Description
Previously, the Operator panicked if one connection (either main or fallback) failed.
The previous solution to this (#1692) was to iterate infinitely over both connections, this had the "silent failure" problem, as an operator could fail and retry forever without notice to its owner.
Now if one connection fails, the Operator will use the other one, while continiously trying to reconnect to the failed one; and if both connections fail, and the retryables are consumed, the Operator will exit, logging the errors of each connection RPC, so the owner/manager of the Operator server can fix it accordingly.
This PR also added the usage of fallback when operator calls
DisableVerifiersTo test
reth-2andreth-3.reth-3is set as the fallback of the operator andreth-2as the main node:Type of change
Please delete options that are not relevant.
Checklist
testnet, everything else tostaging