Test Details Overview

Fix race condition in confirm_quorum test (#5096)

node.confirm_quorum intermittently failed on slow/contended CI runners at
ASSERT_EQ (1, election->votes ().size ()) with a value of 2. Between
processing send1 and the send_action that drained genesis below quorum, the
backlog scheduler could activate send1's election while genesis was still a
heavy principal representative, letting genesis cast a sub-quorum vote that
was cached permanently. The election's confirmation outcome was never at
risk; only the vote-count assertion was racy.

Drain genesis to zero weight through the ledger directly and insert the
voting key only once that is done, so genesis can never vote on the election
while it still holds weight, regardless of scheduler timing.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

__________

Type: commit

Hash: d91fa07c42e47264f5b0fcc815db837858df0bb5

Created: 24 day(s) ago

__________

gr0v1ty/nano-node:d91fa07c42e47264f5b0fcc815db837858df0bb5

Test Results

Test Case Status Duration Median Deviation Log Graph
5n4pr_conf_10k_bintree PASS 108 s -11.0 s - Show
5n4pr_conf_10k_change PASS 215 s 55.0 s - Show
5n4pr_conf_change_dependant PASS 109 s -7.0 s - -
5n4pr_conf_change_independant PASS 117 s 2.0 s - -
5n4pr_conf_send_dependant PASS 110 s -9.0 s - -
5n4pr_conf_send_independant PASS 111 s -7.0 s - -
5n4pr_rocks_10k_bintree PASS 113 s -5.0 s - -
5n4pr_rocks_10k_change PASS 227 s 51.0 s - -