-
Notifications
You must be signed in to change notification settings - Fork 156
derive target epoch from proposal in proposal prelim validated handler #3808
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: main
Are you sure you want to change the base?
Conversation
|
First one after last commit had one failure: https://github.com/EspressoSystems/espresso-network/actions/runs/19857550770/job/56899382310?pr=3808, this is a CDN crash test. CDN goes down at 5, comes back at 13. Failed viewes 17,18,19. Feels like it should be unrelated. |
|
Runs: |
| .block_number | ||
| .is_some_and(|bn| is_last_block(bn, self.epoch_height)) | ||
| { | ||
| qc_epoch.map(|e| e + 1) |
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.
To make sure that it's a valid extended QC we should also check whether the proposal has the corresponding next_epoch_justify_qc. You can get it with the method next_epoch_justify_qc() and you can check whether the two certificates correspond to each other by comparing their leaf commits. They should be the same.
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 you should actually be able to use handle_eqc_formed method to also properly store the eQC received in this way.
No description provided.