-
Notifications
You must be signed in to change notification settings - Fork 53
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
Make Membership::leader()
return a Result<_>
#3738
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.
Started reviewing, changing membership and using ensure seems like a good change, but I think we need to resolve the issue with log levels.
Also this pr can get a bit smaller after: #3755 merges
@@ -108,35 +108,31 @@ impl<TYPES: NodeType, I: NodeImplementation<TYPES>, V: Versions> DaTaskState<TYP | |||
// the `DaProposalRecv` event. Otherwise, the view number subtraction below will | |||
// cause an overflow error. | |||
// TODO ED Come back to this - we probably don't need this, but we should also never receive a DAC where this fails, investigate block ready so it doesn't make one for the genesis block |
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.
Can we resolve this TODO comment? I don't think receiving a proposal has much to do with the block ready event. A bad leader could send us proposals for old views so we need this check to discard them early.
Longer term follow up, what if we get a valid DAProposal late, is there any value in backfilling the leaf with the full block data?
With my PR having merged (3755) this one will need to be rebased |
d23ec22
to
f6c3d19
Compare
This PR:
Makes the
leader
function fallible, returning ananyhow::Result
. As a consequence of this, a lot of task logic was refactored to also return ananyhow::Result
.This PR does not:
This is not a complete refactor towards returning
anyhow::Result
from all tasks, but it moves us most of the way towards that.Key places to review:
It's worth checking that each
ensure!
is equivalent (or in some cases, more correct) than the original conditional everywhere these were replaced.