-
Notifications
You must be signed in to change notification settings - Fork 866
Fix and test fork revert logic #5100
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
base: unstable
Are you sure you want to change the base?
Conversation
0ccf80e
to
cdc8416
Compare
0a913d4
to
641f6be
Compare
4f1bcf1
to
cfe51b1
Compare
cfe51b1
to
d8ae9b2
Compare
I've made some progress upgrading the local testnet infra that would be necessary to solve the issue. But I ran into some problems, and don't know where to go from here. My intent with this comment is to explain what I'm trying to do and hope that someone points to the mistakes that I'm making. A tl;dr of the
This is pretty much the test that Michael described here: #4198 (comment). I think I'm close to getting it to work, but I'm getting some unexpected behavior. After step 4, the non-stale nodes' logs will include:
and the stale nodes will only include:
With no mention of deneb, as expected! We wait until slot 64, the non-stale nodes will log:
And the stale nodes will not log anything related to deneb but their updates will start looking like this:
I think this is the expected behavior, since they missed the fork, they will keep advancing the slots but won't get info about any new block. After the timeout ends, they get updated and reconfigured. I was expecting to get something like this: #4188 (comment). But instead, they just... recover?
I guess that I'm misunderstanding how the fork transition is defined; and that deleting the deneb lines on the config.yaml file is not enough. But I don't know how else I could do it. Is there something obviously wrong with my approach? |
@danielramirezch I think the missing ingredient is a block on the stale chain for the wrong fork version. That's what will mess up the DB badly, because the head block will be at the wrong fork. If there are just empty slots on the stale chain then there's nothing in need of reversion |
setup.sh will fail if this line is not deleted
Issue Addressed
#4198
Proposed Changes
wip