-
Notifications
You must be signed in to change notification settings - Fork 271
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
feat: allow changing L1 synced height via admin RPC/CLI #1044
base: develop
Are you sure you want to change the base?
Conversation
How about we check if the new |
I found this brings up another issue, if someone updates the height to a very small height (e.g. block 1, which is << the deployment height), the height cannot be increased through this rpc. |
eth/api.go
Outdated
|
||
// SetRollupEventSyncedL1Height sets the synced L1 height for rollup event synchronization | ||
func (api *ScrollAPI) SetRollupEventSyncedL1Height(height uint64) error { | ||
rollupSyncService := api.eth.GetRollupSyncService() |
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.
I think don't expose it to api, it's too dangerous, just cmd. Because any internal staff can connect to API and reset the height by API.
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.
nice catch. currently moved to "admin" namespace in e39cdb1.
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.
RPC providers do not expose the scroll_
namespace: https://bit.ly/scroll-l2geth-rpc. But I agree it is better to have this in the admin_
namespace.
local test:
|
s.resetMu.Lock() | ||
defer s.resetMu.Unlock() | ||
|
||
s.Stop() |
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.
Why do we need to stop and restart?
Instead, we should just project latestProcessedBlock
with a lock (i.e. lock in fetchMessages
and ResetToHeight
.
Then we also don't need to reinitialize the context here.
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.
aha, it makes sense. changed in c588232, currently, there are some read/write ops related latestProcessedBlock
and db
, thus added a function level write lock.
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.
refactored to use atomic.Uint64
for latestProcessedBlock
in 75413e6.
rollup/sync_service/sync_service.go
Outdated
s.stateMu.Lock() | ||
defer s.stateMu.Unlock() | ||
|
||
rawdb.WriteSyncedL1BlockNumber(s.db, height) |
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.
I don't think you need to do this, no? flush()
in fetchMessages
will do that anyways.
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.
Probably same applies to (s *RollupSyncService) ResetToHeight
as well
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.
changed in 75413e6.
rollup/sync_service/sync_service.go
Outdated
@@ -50,6 +51,8 @@ type SyncService struct { | |||
pollInterval time.Duration | |||
latestProcessedBlock uint64 | |||
scope event.SubscriptionScope | |||
|
|||
stateMu sync.Mutex // protects the service state, e.g. db and latestProcessedBlock updates |
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.
I would expect simply making latestProcessedBlock
an atomic.Uint64
would work just fine instead of adding a mutex here.
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.
changed in 75413e6.
1. Purpose or design rationale of this PR
For two typical errors in the logs:
2. PR title
Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:
3. Deployment tag versioning
Has the version in
params/version.go
been updated?4. Breaking change label
Does this PR have the
breaking-change
label?