Unverified Commit c44a50bb authored by Jay Guo's avatar Jay Guo Committed by Artem Barger
Browse files

[FAB-14031] Fix flake in etcdraft UT



After reconnect the leader to network, we tick it to resend
previous data. However, if it's ticked too excessively, it
may step down to follower due to `CheckQuorum` being enabled.
This causes the test to fail.

Instead of ticking it, this CR changes one test to simply
enque one more tx to trigger resend of previous data.

Change-Id: I211c7bf59dc6322509336ed8b120d869ea1f42f6
Signed-off-by: default avatarJay Guo <guojiannan1101@gmail.com>
parent 566562e7
......@@ -2009,25 +2009,19 @@ var _ = Describe("Chain", func() {
c1.cutter.CutNext = true
for i := 0; i < 3; i++ {
err := c1.Order(env, 0)
Expect(err).NotTo(HaveOccurred())
Expect(c1.Order(env, 0)).To(Succeed())
}
Consistently(c1.support.WriteBlockCallCount).Should(Equal(0))
network.connect(1)
// keep ticking leader until all the blocks are replicated and committed.
// Otherwise, if we only tick once, and leader was still preserving block
// data to disk due to long wal sync, this tick may be dropped and cannot
// trigger retransmission of messages upon reconnection.
Eventually(func() int {
c1.clock.Increment(interval)
return c1.support.WriteBlockCallCount()
}, LongEventualTimeout).Should(Equal(3))
// Enque another env to trigger resend of previous data
Expect(c1.Order(env, 0)).To(Succeed())
Eventually(c2.support.WriteBlockCallCount, LongEventualTimeout).Should(Equal(3))
Eventually(c3.support.WriteBlockCallCount, LongEventualTimeout).Should(Equal(3))
network.exec(func(c *chain) {
Eventually(c.support.WriteBlockCallCount, LongEventualTimeout).Should(Equal(4))
})
})
It("new leader should wait for in-fight blocks to commit before accepting new env", func() {
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment