We do this to trigger a bug that will be resolved in a follow-up commit.
This bug prevents inbound legacy channels from being rejected by the
recipient if they have at least one anchor channel already opened
without an on-chain balance.
This commit refactors the resumePayment to extract some logics back to
paymentState so that the code is more testable. It also adds unit tests
for paymentState, and breaks the original MPPayment tests into independent tests
so that it's easier to maintain and debug. All the new tests are built
using mock so that the control flow is eaiser to setup and change.
This commit renames the mock structs by appending Old in their names. In
doing so the old tests stay unchanged and new mock structs can be added
in the following commit.
This commit adds payment session to shardHandler to enable private edge
policies being updated in shardHandler. The relevant interface and mock
are updated. From now on, upon seeing a ChannelUpdate message,
shardHandler will first try to find the target policy in additionalEdges
and update it. If nothing found, it will then check the database for
edge policy to update.
This commit adds the method UpdateAdditionalEdge in PaymentSession,
which allows the addtional channel edge policy to be updated from a
ChannelUpdate message. Another method, GetAdditionalEdgePolicy is added
to allow querying additional edge policies.
This commit moves the handleSendError method from ChannelRouter to
shardHandler. In doing so, shardHandler can now apply updates to the
in-memory paymentSession if they are found in the error message.
The simulated error returned was rejected due to signature failure,
and didn't simulate correctly the insufficient fees error as
intended. Fix error by including correct signature.
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.
The monitoring server still needs to be enabled using prometheus.enable,
so including this in the default build does not add an additional http
server unless the user opts in.
