contractcourt: fix off-by-one error in closeObserver case

In this commit, we fix an off-by-one error when handling force closes
from the remote party. Before this commit, if the remote party
broadcasts state 2, and we were on state 1, then we wouldn't act at all.
This is due to an extraneous +1 in the comparison, causing us to only
detect this DLP case if the remote party's state is two beyond what we
know atm. Before this commit, the test added in the prior commit failed.
This commit is contained in:
Olaoluwa Osuntokun 2019-03-12 19:25:01 -07:00
parent 795c9f1550
commit 6983a9e146
No known key found for this signature in database
GPG key ID: CE58F7F8E20FD9A2

View file

@ -406,11 +406,12 @@ func (c *chainWatcher) closeObserver(spendNtfn *chainntnfs.SpendEvent) {
c.cfg.chanState.FundingOutpoint, err) c.cfg.chanState.FundingOutpoint, err)
} }
// This is the case that somehow the commitment broadcast is // If the remote party has broadcasted a state beyond our best
// actually greater than even one beyond our best known state // known state for them, and they don't have a pending
// number. This should ONLY happen in case we experienced some // commitment (we write them to disk before sending out), then
// sort of data loss. // this means that we've lost data. In this case, we'll enter
case broadcastStateNum > remoteStateNum+1: // the DLP protocol.
case broadcastStateNum > remoteStateNum:
log.Warnf("Remote node broadcast state #%v, "+ log.Warnf("Remote node broadcast state #%v, "+
"which is more than 1 beyond best known "+ "which is more than 1 beyond best known "+
"state #%v!!! Attempting recovery...", "state #%v!!! Attempting recovery...",