This commit adds PendingOpenChannel to SubscribeChannelEvents stream in
the gRPC API.
This is useful for keeping track of channel openings that Autopilot does.
It can also be used for the non-initator side of a channel opening to keep
track of channel openings.
In this commit, we change the release script slightly to return the
latest tag if there're multiple tags at head. Otherwise the release
script will fail if our final tag is at the same commit as the prior
release candidate tag.
Returning from the sendPayments method closes the underlying stream, so
we would risk payments still being in flight when returning.
We add the running goroutines to a waitgroup, such that we can wait for
them all to exit before exiting and closing the stream.
In case an error is encountered in the process, we will return directly,
which will close the `reqQuit` channel and prompt the gorpoutines to
shut down.
This commit fixes a problem that could arise when handling a continuous
stream of payIntents. We would risk the client sending a set of payment
intents and closing the stream, but we wouldn't be sure the sendLoop had
read all messages on the `payChan` before exiting with the nil error
from the `errChan`.
Instead, we close the `payChan` to indicate that no more payments are
going to be received.
This commit fixes a potential issue in the bidirectional sendPayment
case, where multiple goroutines could be sending on an errChan with
buffer 1. Instead we select on default as well, as it is enough to
handle the first error that was received.
Intead of checking for shutdown in the receive loop, we let the sendLoop
handle it, as it can return the error directly. This works since the
returning sendLoop will trigger a close of the `reqQuit` channel, which
will ensure the receive loop exits.
Previously we only penalized the outgoing connections of a failing node.
This turned out not to be sufficient, because the next route sometimes
went into the same failing node again to try a different outgoing
connection that wasn't yet known to mission control and therefore not
penalized before.
To ensure lnd is able to pick up an on-chain preimage properly after a
restart, we suspend Alice and check that the payment is listed correctly
as succeeded after a restart.
If the provided ChainHash in a QueryChannelRange message does not match
that of our current chain, then we should send a blank response, rather
than reply with channels for the wrong chain.
This shortcut does not work when the destination is a private node. We
also don't have this shortcut for regular payments. This commit
aligns the behavior between SendPayment and QueryRoutes.
This commit updates the channel state machine to
persistently store remote updates that we have received a
signature for, but that we haven't yet included in a commit
signature of our own.
Previously those updates were only stored in memory and
dropped across restarts. This lead to the production of
an invalid signature and channel force closure. The remote
party expects us to include those updates.
This test asserts that remote updates that are locked-in on the local
commitment, but haven't been signed for on the remote commitment, are
properly restored after a restart.
The default was increased for the main sendpayment RPC in commit
d3fa9767a9729756bab9b4a1121344b265410b1a. This commit sets the
same default for QueryRoutes, routerrpc.SendPayment and
router.EstimateRouteFee.
Update the ChannelLink interface to specifically
return the LinkError struct. This error implements
the ClearTextError interface, so will be picked
up as a routing realted error by the router.
With LinkErrors implemented, the switch now
returns a LinkError for all failures on our
incoming/outgoing link and ForwardingError when
the failure occurs down the line.
Update the type check used for checking local payment
failures to check on the ClearTextError interface rather
than on the ForwardingError type. This change prepares
for splitting payment errors up into Link and Forwarding
errors.
This change introduces a LinkError implementation
of the ClearTextError interface. This error is intended
to represent failures which occur on our incoming and
outgoing link when sending, receiving and forwarding
htlcs. Paired with ForwardingError, which is represents
failures that did not occur at our node, this error
covers all non-opaque errors that the switch experiences.
