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.
Here we fix a bug which would not include the selected incoming blinded
path chain from being included in the selected path set if it meets the
minimum length requirement. The appropriate unit test and itest is
updated to demonstrate the fix.
The itest framework now handles the closure of any channels opened
during the test and so we dont need to manually close them. The manual
closure code in the route blinding tests were resulting in the
occasional test flake.
Since we don't have standby nodes anymore, we don't need to close the
channels when the test finishes. Previously we would do so to make sure
the standby nodes have a clean state for the next test case, which is no
longer relevant.
This commit removes the usage of the standby nodes and uses
`CreateSimpleNetwork` when applicable. Also introduces a helper method
`NewNodeWithCoins` to quickly start a node with funds.
Prepares the upcoming refactor. We now never call `ht.Alice` directly,
instead, we always init `alice := ht.Alice` so it's easier to see how
they are removed in a following commit.
This commit replaces `AssertTopologyChannelOpen` with
`AssertChannelInGraph`, which asserts a given channel edge is found.
`AssertTopologyChannelOpen` only asserts a given edge has been received
via the topology subscription, while we need to make sure the channel is
in the graph before continuing our tests.
This commit fixes the instantiation of the BlindingPoint member of
PaymentDescriptor during the conversion from persisted LogUpdates.
Previously, the blinding point was not set correctly. The test from the
previous commit is also updated to now assert that this behaviour is now
correct.
This commit adds a new route blinding itest that demonstrates that the
reloading and re-forwarding of an UpdateAddHTLC message on restart
currently is done incorrectly for a blinded path payment. This is due to
the fact that the blinding point member is not currently set correctly.
This is fixed in the next commit which will also change the test to
assert that the behaviour is now correct.
The BlindedPathConfig struct is nice for invoice creation but when we
use the Invoice message for viewing an invoice, it would be nicer to see
an "is_blinded" field.
Add an itest that tests the addition of dummy hops to a blinded path. By
testing that invoices containing such a path can be paid, it also tests
the peeling of dummy hops by the receiver.
Make various sender side adjustments so that a sender is able to send an
MP payment to a single blinded path without actually including an MPP
record in the payment.
Update one of the route blinding itests to do a full end-to-end test
where the recipient generates and invoice with a blinded path and the
sender just provides that invoice to SendPayment.
The tests also covers the edge case where the recipient is the
introduction node.
The route blinding itests are now updated so that recipient logic is
tested. The creation of a blinded route is also now done through the
AddInvoice API instead of manually.
For the final hop in a blinded route, the SCID and RelayInfo fields will
_not_ be set. So these fields need to be converted to optional records.
The existing BlindedRouteData constructor is also renamed to
`NewNonFinalBlindedRouteData` in preparation for a
`NewFinalBlindedRouteData` constructor which will be used to construct
the blinded data for the final hop which will contain a much smaller set
of data. The SCID and RelayInfo parameters of the constructor are left
as non-pointers in order to force the caller to set them in the case
that the constructor is called for non-final nodes. The other option
would be to create a single constructor where all parameters are
optional but I think this makes it easier for the caller to make a
mistake.
We may get a flake like the following,
```
lnd_route_blinding_test.go:468:
Error Trace: /Users/runner/work/lnd/lnd/itest/lnd_route_blinding_test.go:468
/Users/runner/hostedtoolcache/go/1.22.3/arm64/src/runtime/asm_arm64.s:1222
Error: Received unexpected error:
rpc error: code = Canceled desc = context canceled
Test: TestLightningNetworkDaemon/tranche15/144-of-156/bitcoind/disable_introduction_node
```
This happens when the test successfully finishes, the parent context is
canceled, causing the child context to return an error. We fix it by
ignoring it in the goroutine.
We mine quite a few blocks in this test to trigger a htlc timeout,
so it can be pretty slow. This fix adds assertions for additional
"state steps" that happen in between the failing of the htlc on-chain
and asserting that we're fully cleared out so that slower running
machines won't timeout.
This itest adds a test that we still propagate blinded errors back
properly after a restart with an on-chain resolution. The test also
updates our sendpayment timeout to longer so that there's time to
resolve the on chain claim.
We don't support receiving blinded in this PR - just intercept and
settle instead. The HTLC's arrival on the interceptor indicates that
it was successfully forwarded on a blinded hop.
Olaoluwa Osuntokun