Repository navigation
Conversation
yacovm
reviewed
Oct 18, 2026
| return msg.VoteMessage == nil || msg.VoteMessage.Vote.Round != 0 | ||
| }, | ||
| ) | ||
|
|
Collaborator
There was a problem hiding this comment.
I'm not sure I understand why skipping the lagging node has any difference.
Isn't the bug here that the lagging node sends its vote too fast before we disconnect it?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The problem was a race between the lagging node's
persistAndBroadcastNotarizationand the test. That function writes the notarization to the WAL and then broadcasts it, solaggingNode.WAL.AssertNotarization(0)can return before the broadcast happens.The test then disconnects the lagging node and calls
SetAllNodesMessageFilter, which replaces every node's filter, including the lagging node's, with one that only blocks round 0 votes.TestComm.Broadcastchecks whether the sender is disconnected once up front, then reads the filter per recipient. So if the laggingnode was in
Broadcastbefore the call toDisconnectand reached the loop after the filter swap, its notarization passed the new filter (the oldsendVotesToOneNodefilter dropped notarizations) and reached the other nodes.AdvanceWithoutLeader(0, ...)then failed because those nodes notarized round 0 instead of timing out.The fix is to set the new filter only on the other nodes, so the lagging node keeps its original filter while disconnected. It gets the new filter right before
net.Connect.Closes #466