From e54f1ea4dbe59b2e53a94774995ae1711746c2f8 Mon Sep 17 00:00:00 2001 From: Olaoluwa Osuntokun Date: Thu, 3 May 2018 19:14:31 -0700 Subject: [PATCH] test: account for block race by mining additional block in remote htlc force close test This commit is similar to a recent commit which attempts to account for internal block races by mining a second block if the initial assertion for HTLC state fails. This can happen again if by the time that the sweeping transaction is broadcast, it doesn't make it into the next block mine. --- lnd_test.go | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/lnd_test.go b/lnd_test.go index 622aa0d3257..80db450074e 100644 --- a/lnd_test.go +++ b/lnd_test.go @@ -7079,9 +7079,20 @@ func testMultHopRemoteForceCloseOnChainHtlcTimeout(net *lntest.NetworkHarness, nodes = []*lntest.HarnessNode{net.Alice} err = lntest.WaitPredicate(func() bool { return assertNumActiveHtlcs(nodes, 0) - }, time.Second*15) + }, time.Second*8) if err != nil { - t.Fatalf("alice's channel still has active htlc's") + // It may be the case that due to a race, Bob's sweeping + // transaction hasn't yet been confirmed, so we'll mine another + // block to nudge it in. If after this it still Alice will has + // an HTLC, then it's actually a test failure. + if _, err := net.Miner.Node.Generate(1); err != nil { + t.Fatalf("unable to generate block: %v", err) + } + if err = lntest.WaitPredicate(func() bool { + return assertNumActiveHtlcs(nodes, 0) + }, time.Second*8); err != nil { + t.Fatalf("alice's channel still has active htlc's") + } } // Now we'll check Bob's pending channel report. Since this was Carol's