From 6983a9e1467af6b16c04491b9816c8bb82c32870 Mon Sep 17 00:00:00 2001 From: Olaoluwa Osuntokun Date: Tue, 12 Mar 2019 19:25:01 -0700 Subject: [PATCH] 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. --- contractcourt/chain_watcher.go | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/contractcourt/chain_watcher.go b/contractcourt/chain_watcher.go index a658d0236..ec60c847a 100644 --- a/contractcourt/chain_watcher.go +++ b/contractcourt/chain_watcher.go @@ -406,11 +406,12 @@ func (c *chainWatcher) closeObserver(spendNtfn *chainntnfs.SpendEvent) { c.cfg.chanState.FundingOutpoint, err) } - // This is the case that somehow the commitment broadcast is - // actually greater than even one beyond our best known state - // number. This should ONLY happen in case we experienced some - // sort of data loss. - case broadcastStateNum > remoteStateNum+1: + // If the remote party has broadcasted a state beyond our best + // known state for them, and they don't have a pending + // commitment (we write them to disk before sending out), then + // this means that we've lost data. In this case, we'll enter + // the DLP protocol. + case broadcastStateNum > remoteStateNum: log.Warnf("Remote node broadcast state #%v, "+ "which is more than 1 beyond best known "+ "state #%v!!! Attempting recovery...",