Fix timing issue in active_elections.fork_replacement_tally

[gr0vity-dev]

This testcase fails in ~10% of cases on my machine with

Expected equality of these values:
  max_blocks
    Which is: 10
  election->blocks ().size ()
    Which is: 1

By waiting for election insertion for the first block, before processing forks, this timing issue is eliminated.

[gr0vity-dev-bot]

Test Results for Commit 9a92ec2

Pull Request 4802: Results
Overall Status: ✅

Test Case Results

• ✅ 5n4pr_conf_10k_bintree: PASS (Duration: 111s)
• ✅ 5n4pr_conf_10k_change: PASS (Duration: 186s)
• ✅ 5n4pr_conf_change_dependant: PASS (Duration: 135s)
• ✅ 5n4pr_conf_change_independant: PASS (Duration: 130s)
• ✅ 5n4pr_conf_send_dependant: PASS (Duration: 134s)
• ✅ 5n4pr_conf_send_independant: PASS (Duration: 125s)
• ✅ 5n4pr_rocks_10k_bintree: PASS (Duration: 113s)
• ✅ 5n4pr_rocks_10k_change: PASS (Duration: 195s)

Last updated: 2024-12-05 15:17:41 UTC

[pwojcikdev]

Shouldn't this be true for every iteration, not just the first?

[gr0vity-dev]

Yes, we could make the assert more general for every iteration.