From 5476f6d310cd2c1a3e6584218907a4a8a0bc0c7b Mon Sep 17 00:00:00 2001 From: "Johan T. Halseth" Date: Tue, 14 Aug 2018 09:09:02 +0200 Subject: [PATCH] contractcourt/contract_resolvers: correct off-by-one HTLC expiry This commit attempts to fix an inconsistency in when we consider an HTLC to expire. When we first launched the resolver we would compare the current block height against the expiry, while for new incoming blocks we would compare against expiry-1. This lead to a flake during integration tests, during a call to RestartNode after _exactly_ enough blocks for the HTLC to expire. In some cases the resolver would see the new blocks and consider the HTLC to be expired (because of the -1), while in some cases resolver would shut down before seeing the new blocks, and upon restart wouldn't act on the new height because we did not compare against -1. This commit fixes this by doing the same comparison in both cases. --- contractcourt/contract_resolvers.go | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/contractcourt/contract_resolvers.go b/contractcourt/contract_resolvers.go index 661ee9d0..7b8be486 100644 --- a/contractcourt/contract_resolvers.go +++ b/contractcourt/contract_resolvers.go @@ -845,7 +845,11 @@ func (h *htlcOutgoingContestResolver) Resolve() (ContractResolver, error) { if err != nil { return nil, err } - if uint32(currentHeight) >= h.htlcResolution.Expiry { + + // If the current height is >= expiry-1, then a spend will be valid to + // be included in the next block, and we can immediately return the + // resolver. + if uint32(currentHeight) >= h.htlcResolution.Expiry-1 { log.Infof("%T(%v): HTLC has expired (height=%v, expiry=%v), "+ "transforming into timeout resolver", h, h.htlcResolution.ClaimOutpoint)