Skip to content
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

replay: votes made before restart are eligible for refresh #34737

Merged
merged 3 commits into from
Feb 6, 2024

Conversation

AshwinSekar
Copy link
Contributor

Problem

Bug in #32315 disallows the last vote to be refreshed after a restart.
This was previously allowed before that change.

Summary of Changes

Distinguish a failed vote vs an uninitialized tower from restart.

@AshwinSekar AshwinSekar changed the title replay: votes made before restart are eligble for refresh replay: votes made before restart are eligible for refresh Jan 10, 2024
@AshwinSekar AshwinSekar marked this pull request as ready for review January 11, 2024 02:59
Copy link

codecov bot commented Jan 11, 2024

Codecov Report

Attention: 18 lines in your changes are missing coverage. Please review.

Comparison is base (0569304) 81.6% compared to head (1addd02) 81.6%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master   #34737   +/-   ##
=======================================
  Coverage    81.6%    81.6%           
=======================================
  Files         830      830           
  Lines      224828   224845   +17     
=======================================
+ Hits       183504   183519   +15     
- Misses      41324    41326    +2     

core/src/consensus.rs Outdated Show resolved Hide resolved
@@ -2511,6 +2516,8 @@ impl ReplayStage {
})
.unwrap_or_else(|err| warn!("Error: {:?}", err));
last_vote_refresh_time.last_refresh_time = Instant::now();
} else {
tower.last_vote_tx_blockhash_failed();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm we only want to mark this as failed if this is a non-voter right? It seems like there's a few other cases where generate_vote_tx can return None though.

Same is true for the other place where this is called

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-voter is just one example. generate_vote_tx could fail for multiple reasons. In that case the vote is already in the tower under last_vote but we haven't propagated it to the network.

I think there's no point attempting to refresh the vote if the last generate_vote_tx failed as the generate_vote_tx for the refreshed vote should fail again. In steady state all of the checks in that function should be deterministic.

However if you prefer I don't mind keeping the scope to just the authorized_voter_keypair check, which is what the --no-voting flag does.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm, seems like we should differentiate a failed vote from somebody that's never voting. Grouping them together seems bound to cause avoid future confusion/bugs.

I would limit the scope if possible

#[default]
Uninitialized,
/// Failed generation of last vote tx
Failed,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this is just to cover the non-voter case, can we make this more specific and call it NotVoting

@github-actions github-actions bot added stale [bot only] Added to stale content; results in auto-close after a week. and removed stale [bot only] Added to stale content; results in auto-close after a week. labels Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants