In this commit, we fix a bug that would cause attempts to re-use an AMP
invoice to fail. Without this commit, we would only attempt to parse the
payment addr if no invoice was specified, so a user manually specifying the
pubkey of the detonation. The fix is straight forward: always parse the
`pay_addr` field as the user may be attempting to re-use an AMP invoice w/o
open coding each of the sections.
* server: disable DNS boostrap for SigNet nodes
In this commit, we fix a bug that would cause nodes attempting to run
using the signet chain, to waste CPU as they attempted to boostrap to a
non-existent DNS seed. We fix this by ignoring the DNS boostrapper is
signet is active. Along the way, we refactor the conditional sightly to
be more readable, and easily extensible.
* server: extract bootstrap logic into new function w/ unit test
* docs/release-notes: update release notes for signet DNS fix
In this commit, we fix a bug that would cause nodes attempting to run
using the signet chain, to waste CPU as they attempted to boostrap to a
non-existent DNS seed. We fix this by ignoring the DNS boostrapper is
signet is active. Along the way, we refactor the conditional sightly to
be more readable, and easily extensible.
Without this commit, the build may break if a PR commit is created, as
that shows the `PR_NUMBER` field we parse out as "master", reflecting
that its a merge commit into the master branch.
In this commit, we add a simple bash script to parse out the current PR
number from an environment variable in the GH actions context, and use
that to check to see if the PR has been referenced in the release notes
or not. This isn't 100% fool proof, but it should catch most of the
common cases.
In this commit, we attempt to fix a race condition that may occur in the
current AMP and MPP tests.
It appears the following scenario is possible:
* The `mppTestContext` [is used to create 6 channels back to
back](https://github.com/lightningnetwork/lnd/blob/master/lntest/itest/lnd_amp_test.go#L43)
* The method used to create the channel ends up calling
[`openChannelAndAssert`](https://github.com/lightningnetwork/lnd/blob/edd4152682dc8f70e11da541cd3be4692db4b011/lntest/itest/lnd_mpp_test.go#L300)
which'll open the channel, mine 6 blocks, [then ensure that the
channel gets
advertised](https://github.com/lightningnetwork/lnd/blob/edd4152682dc8f70e11da541cd3be4692db4b011/lntest/itest/assertions.go#L78)
* Later on, [we wait for all nodes to hear about all channels on the
network
level](https://github.com/lightningnetwork/lnd/blob/master/lntest/itest/lnd_amp_test.go#L62)
I think the issue here is that we'll potentially already have mined 30
or so blocks before getting to the final nodes, and those nodes may have
already heard about the channel already. This may then cause their
[`lightningNetworkWatcher`](https://github.com/lightningnetwork/lnd/blob/edd4152682dc8f70e11da541cd3be4692db4b011/lntest/node.go#L1213)
goroutine to not properly dispatch this, since it's assumed that the
channel hasn't been announced (or notified) when the method is called.
One solution here is to just check if the channel is already in the
node's graph or not, when we go to register the notification. If we do
this in the same state machine as the watcher, then we ensure if the
channel is already known, the client is immediately notified. One thing
that can help us debug this more in the future is adding additional
logging in some of these helper goroutines so we can more easily track
the control flow.
This commit implements this solution by checking to ensure that the
channel isn't already known in our channel graph before attempting to
wait for its notification, as we may already have missed the
notification before this registration request came in.
In this commit, we fix a regression introduced by a recent bug fix in
this area. Before this change, we'd inspect the error returned by
`processSendError`, and then fail the payment from the PoV of mission
control using the returned error.
A recent refactoring removed `processSendError` and combined the logic
with `tryApplyChannelUpdate` in order to introduce a new
`handleSendError` method that consolidates the logic within the
`shardHandler`. Along the way, the behavior of the prior check was
replicated in the form of a new internal `failPayment` closure. However,
the new function closure ends up returning a `channeldb.FailureReason`
instance, which is actually an `error`.
In the wild, when `SendToRoute` fails due to an error at the
destination, then this new logic caused the `handleSendErorr` method to
fail with an error, returning an unstructured error back to the caller,
instead of the usual payment failure details.
We fix this by no longer checking the `handleSendErorr` for an error as
normal. The `handleSendErorr` function as is will always return an error
of type `*channeldb.FailureReason`, therefore we don't need to treat it
as a normal error. Instead, we check for the type of error returned, and
update the control tower state accordingly.
With this commit, the test added in the prior commit now passes.
Fixes#5477.
In this commit, we modify the existing `TestSendToRouteStructuredError`
test to return an error that doesn't trigger the second chance logic.
Otherwise, we'll get a nil failure result from the mission control
interpretation, meaning we won't exercise the full code path. Instead,
we use a terminal error to ensure that the expected code path is hit.
As is, this test will fail as a recent refactoring causes us to return a
`channeldb.FailureReason` error, since the newly added `handleSendError`
code path in the `SendToRoute` method will return the raw error, rather
than the `shardError`, which is of the expected type.
In this commit, in order to allow the test added in the prior commit to
pass, we'll increment the mockHTLCAmt value by 1 to ensure we never
attempt to add a zero value HTLC.
Fixes#5468
As is, if the remote party proposes a min HTLC of 0 `mSat` to us, then
we won't ever be able to _send outgoing_ in the channel as the
`MayAddOutgoingHtlc` will attempt to add a zero-value HTLC, which isn't
allowed within the protocol.
The default channels created actually already use a min HTLC value of
zero within the tests, so this test case fails as is.
In #5364 we added a new error path in the `StopDaemon` method to return
an error if shutdown was attempted while a rescan/recover instance was
in progress. Since the wallet actually won't fully stop (atm)
mid-recovery, the call effectively didn't do anything in that scenario,
so we started to return an error to properly reflect that. However this
causes certain itests to fail, as during recovery, the stop attempt will
fail leading to the test itself failing.
In this commit, we wrap the calls to stop a running daemon within a
`wait.NoError` call so we'll continually try to shut down the daemon
rather than quit on the first try.
Fixes#5423.
In this commit, we add a new folder within the `docs` directory that will
house the release notes for all versions of `lnd` going forward. Moving to
use `git` for the release notes rather than the normal drafting procedure
lets us keep track of the set of changes more consistency over time, lets
contributors add their release notes over time, and also means we'll no
longer need to do a crunch at the tail end of the release process to fill in
the set of release notes.
For the 0.13.1 release notes, I've done a scan and added anything that has
been merged since the last major version tag. In a follow up change, we'll
add a new Github action that fails the build if an entry in the release
notes linking to the newly added PR isn't committed as well. Until then, any
PRs merged in should ensure that they add an entry within the relevant
milestone.
Olaoluwa Osuntokun