Fix consensus sync peers waiting on wrong value #5350
Conversation
There was a problem hiding this comment.
Seems correct code-wise. But I have the same doubt as Andrey, why is it not better to wait for a higher commit value? In the worse case, there will be a timeout but even that it was waiting for the same time 🤔
Maybe we should pick one of the scenarios (one with snapshot or wal delta transfer) to see if this actually makes a difference?
timvisee
force-pushed
the
fix-consensus-sync-peers
branch
from
06a205e to
b7ab085
Compare
I'm quite confused by this as well, and have no answer to this yet. What I can say is that making this change did have a clear effect on my repro. Even though this is not entirely clear yet I do believe it's better to change it because this is how it should have been from the start.
If you mean - testing in chaos testing - then yes I definitely vote for that. |
* When syncing consensus across peers, wait on last applied index * Update comment * Reformat * Fall back to 0
When synchronizing the consensus commit and peer we were waiting on the wrong commit value.
We waited on the commit in hard state, but we should wait on the last applied entry instead. The last applied entry better reflects what collection metadata we're actually seeing, while the hard state commit might be somewhere in the future.
All Submissions:
devbranch. Did you create your branch fromdev?New Feature Submissions:
cargo +nightly fmt --allcommand prior to submission?cargo clippy --all --all-featurescommand?