akovalenko/lnd.xprv
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

test: account for block race by mining additional block in remote htlc force close test

Browse Source 
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
1 changed files with 13 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
lnd_test.go
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