Use the new feature of Go 1.24, fix linter warnings.
This change was produced by:
- running golangci-lint run --fix
- sed 's/context.Background/t.Context/' -i `git grep -l context.Background | grep test.go`
- manually fixing broken tests
- itest, lntest: use ht.Context() where ht or hn is available
- in HarnessNode.Stop() we keep using context.Background(), because it is
called from a cleanup handler in which t.Context() is canceled already.
Fixes another flake in the unit-race test: Sometimes we miss startup
events if there's a high CPU load (in CI for example).
To avoid that, we register our subscriber before starting the state
machine.
These tests previously only worked because we didn't properly wait for
all transitions to come in. We fix them by correctly asserting the
expected number of state transitions.
This fixes the actual flake: We didn't wait for next iterations to _not_
come in, so depending on timing, we could read another transition in a
second run.
But making sure we expect all transitions at the same time and then make
sure no further transitions come in makes this not depend on time.
The param previously was unused so this was likely an oversight or
copy/paste error.
This does not change any behavior, as the method was always called with
the constant previously used. But it makes things more explicit.
In this commit, we fix a flake in the
`TestRbfCloseClosingNegotiationLocal/send_offer_rbf_wrong_local_script`
test.
This flake can happen if the test shuts down _before_ the state machine
is actually able to process the sent event. In this case, the
expectations are triggered, and we find that the error isn't sent.
To resolve this, we create a new wrapper function that'll use a sync
channel send to assert that the error has been sent before we exit the
test.
In this commit, we fix a flake in the rbf loop sub-test for the
TestRbfCloseClosingNegotiationLocal test case.
The fix here is that when we go from ClosePending for an RBF iteration
loop, we first transition to LocalCloseStart. However we only do this
extra transition if we're doing an iteration (starting from ClosePending).
To fix this, we add a new bool that tracks if this is an iteration or
not. We can then also eliminate the extra assertion at the end, as we'll
terminate in `ClosePending` which is checked by
`assertLocalClosePending()` in `assertSingleRbfIteration`.
Fixes https://github.com/lightningnetwork/lnd/issues/9526.
In this commit, we fix a flake in the
`TestRbfChannelFlushingTransitions/early_offer` test. The fix is simple:
this is actually an "iteration", as we have a self transition to the
ChannelNegotiation state first. We also don't need to send the
remoteOffer, so we set `sendInit` to false. The offer still needs to be
passed in to ensure that the assertions work however.
In this commit, we update the RBF state machine to handle early offer
cases. This can happen if after we send out shutdown (to kick things
off), the remote party sends their offer early. This can also happen if
their outgoing shutdown (to ACK ours) was delayed for w/e reason, and we
get their offer first.
The alternative was to modify the state machine itself, but we feel that
handling this early case is better in line with the Robustness principle.
In this commit, we implement the latest version of the RBF loop as
described in the spec. We remove the self loop back based on sending or
receiving shutdown. Instead, from the ClosePending state, we can trigger
a new loop by sending SendOfferEvent (we bump), or OfferReceivedEvent
(they bump).
We also update the rbf state machine w/ the new close addr logic. This
log ensures that the remote party always sends our current address, and
that if they send a new address, we'll update our view of it, and
counter sign the correct transaction.
We also add a CloseErr state. With this new state, we can ensure that
we're able to properly report errors back to the RPC client, and also
optionally force a reconnection or send a warning to the remote party.
