-
Notifications
You must be signed in to change notification settings - Fork 30
chore(test): Replay WAL before start round #898
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
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #898 +/- ##
===========================
===========================
|
So it looks like one thing missing in step change mux, specifically for this case |
@ancazamfir I added a new |
I think that some issues that may occur with this PR approach are related to the timeouts. In particular if the timeout has been writtedn to wal but its effects (e.g. voting nil) has not before the restart, then after restart we will run the timers. This is because the timeouts in Also we need to add wal tests that include timeouts (if we don't have already). |
As discussed today, let's close this in favor of #896 |
@romac just to clarify, we will still replay (proposals) at start height before start round, meaning most of the changes here should still apply, right? |
Yes, but since the other PR contains most of the changes already I will move what's needed from here to there. |
Closes: #XXX
An experiment for simply moving the WAL replay before start round. If we enter new round with a proposal already we should not
getValue()
again.We should also find all the votes already stored for all rounds, etc.
NewRound mux would need more updates though.edit: it's actually
step_change
mux and it looks pretty complete.PR author checklist
For all contributors
For external contributors