-
Notifications
You must be signed in to change notification settings - Fork 26
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
Use Desired RPC Block Number in Chain Watcher #720
Conversation
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
@@ -204,7 +204,7 @@ func NewAssertionChain( | |||
confirmedChallengesByParentAssertionHash: threadsafe.NewLruSet(1000, threadsafe.LruSetWithMetric[protocol.AssertionHash]("confirmedChallengesByParentAssertionHash")), | |||
averageTimeForBlockCreation: time.Second * 12, | |||
transactor: transactor, | |||
rpcHeadBlockNumber: rpc.FinalizedBlockNumber, | |||
rpcHeadBlockNumber: rpc.LatestBlockNumber, |
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.
Expects the operator to provide the RPC head block number to another value if desired. In Nitro, this will default to Finalized. Using Latest here makes sure that our tests remain fast without needing to change test setups across the whole codebase with options
@@ -108,11 +108,11 @@ type protocolParams struct { | |||
func defaultProtocolParams() protocolParams { |
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.
Reducing values here for faster CI times
This PR discovered that the chain watcher, which scrapes for challenge events from the chain, was not respecting the desired RPC block number configured by the user. For instance, if the software were configured to rely on finalized data, the watcher would just look at latest data and lead to errors at runtime when scraping chain events. Although non-critical, these are still important error logs to avoid in normal operation.
This PR also fixes a bit of log formatting and removes a certain condition of an edge's children not yet being tracked from being an error log. This also occurs when relying on finalized data, but resolves on its own