This permits an AMP invoice to be "pseudo-reusable", where the invoice
paramters can be used multiple times so long as a new payment address is
supplied. This prevents additional round trips between payer and payee
to obtain a new invoice, even though the payments/invoices won't be
logically associated via the RPC interface like they would when the full
reusable invoices are deployed.
Fixes#5307.
Corrects some typos in the REST annotations for the routerrpc subserver.
Unfortunately these mistakes aren't caught by the current version of the
grpc-gateway library. But we intend to update to v2 soon which will
output alerts as mentioned in #5307.
With this patch, we'll fail out earlier in the cycle in case of
some wonky parameters, and not leave zombie payments in the router
which currently are not cleaned up.
This commit adds a new "waiting to start" state which may be used to
query if we're still waiting to become the cluster leader. Once leader
we advance the state to "wallet not exist" or "wallet locked" given
wallet availablity.
Fixes the logged error "WS: error closing upgraded conn: tls: failed to
send closeNotify alert (but connection was closed anyway): write tcp4
<ip>-><ip>: write: connection reset by peer" that is caused by the
client closing the connection on its end.
The grpc-gateway library that is used to transform REST calls into gRPC
uses a different method for reading a request body stream depending on
whether the RPC is a request-streaming one or not. We can't really find
out what kind of RPC the user is calling at runtime, so we add a new
parameter to the proxy that lists all request-streaming RPC calls.
In any case the client _has_ to send one request message initially to
kick off the request processing. Normally this can just be an empty
message. This can lead to problems if that empty message is not
expected by the gRPC server. But for the currently existing two
client-streaming RPCs this will only trigger a warning
(HTLC interceptor) or be ignored (channel acceptor).
Since we want to support AMP payment using a different unique payment
identifier (AMP payments don't go to one specific hash), we change the
nomenclature to be Identifier instead of PaymentHash.
We'd never decrement the number of pending backups upon a watchtower
accepting one, making it confusing for users to determine whether their
backups have actually been accepted. Along the way, we also rename
NumTasksReceived to NumTasksPending to better reflect its purpose.
This commit adds a []*lnrpc.NodeAddress typed node_addresses field
on the NodeUpdate message of SubscribeChannelGraph to mirror the
addresses field in the LightningNode message of DescribeGraph.
Fixes https://github.com/lightningnetwork/lnd/issues/4084
