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.
This commit is contained in:
Olaoluwa Osuntokun 2018-05-03 19:14:31 -07:00
parent 1e7f2c32e9
commit e54f1ea4db
No known key found for this signature in database
GPG Key ID: 964EA263DD637C21

View File

@ -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