Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: prevent multiple block proposal evals #5453
base: develop
Are you sure you want to change the base?
feat: prevent multiple block proposal evals #5453
Changes from 1 commit
3b2726e
4178fb6
a9c7794
014f44b
5384045
0dc1524
5f8f9eb
949088f
90b6fb3
63ae626
2e30240
e522058
b3f9c35
cf345bb
77ef010
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 could maybe have mark_locally or mark_globally etc. functions to just auto update these pending lists because if we have come to a consensus or we are calling these functions, it doens't matter what the block response is/we should no longer consider these as pending block proposals. Does that make sense?
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.
Interesting, good call. That somewhat contrasts the ticket for always sending BlockResponses, but if the block already reached consensus, there's no point in adding load to our node with a new block response. Your suggestion would probably also help mitigate the issue that this PR tries to solve.
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 neither of us noticed this was in
handle_block_response
, nothandle_block_validation_response
🤦. I've moved it tohandle_block_validation_response
.Regarding your point, though, I think we should remove the pending validation when a block is marked globally accepted/rejected. If the validation response comes in after it's marked as globally handled (the "typical" scenario), we'll still respond with a block response, which we want. But if our signer is "catching up", and the pending block validation is 1 or more blocks behind the tip, we should just drop it.