lnrpc: structured SendToRoute failure reporting#1662
lnrpc: structured SendToRoute failure reporting#1662joostjager merged 4 commits intolightningnetwork:masterfrom
Conversation
15be4a3 to
e0d8f80
Compare
30e785a to
7602d53
Compare
|
PR is ready for a first pass review |
1bba17e to
bfac456
Compare
f0ceaf6 to
cb1dc9b
Compare
lnd_test.go
Outdated
There was a problem hiding this comment.
IMO should be carried out before this is merged in.
There was a problem hiding this comment.
As the router rpc is still in experimental state and its interface may change, we could also wait until we actually deprecate the main SendToRoute rpc.
Changing it now also moves coverage away from the main rpc and it may be safer to not yet do that.
lnrpc/rpc.proto
Outdated
There was a problem hiding this comment.
What are the flags here? Aren't they already contained in the channel update?
There was a problem hiding this comment.
I actually don't know. Can you tell me what the flags field in the onion failure message channel_disabled is for?
lnrpc/rpc.proto
Outdated
There was a problem hiding this comment.
Is this the outgoing or incoming CLTV expiry for that hop?
There was a problem hiding this comment.
See comment above
There was a problem hiding this comment.
This is the field as defined in the lightning spec.
lnrpc/rpc.proto
Outdated
There was a problem hiding this comment.
Similar q here: outgoing or incoming?
There was a problem hiding this comment.
This field and other fields in this message contain the raw onion error. I chose not to make it one giant oneof construct, but instead created a union of all failure message fields. The meaning of htlc_msat and also cltv_expiry depends on the actual error.
lnrpc/rpc.proto
Outdated
There was a problem hiding this comment.
Could add a suffix like _pubkey_bytes, just to clarify what the opaque bytes represent.
There was a problem hiding this comment.
Added _pubkey. Also adding bytes is maybe too much and also not what we do in other places in the proto.
lnrpc/rpc.proto
Outdated
There was a problem hiding this comment.
Do we really need to expose the sig on the RPC level? As could say the client already fully trusts the server itself.
There was a problem hiding this comment.
I'd like the signatures, for data portability
899376e to
7806475
Compare
|
What's the status of this PR? Is it on its way to be merged, or has it been replaced/deprioritized? I'm asking mainly due to the fact that good error reporting is needed in order to take full advantage of the new interface of QueryRoutes. |
|
@esneider The plan is to move ahead with this after the release of 0.6.1, as it contains a breaking change. |
4f9207c to
e498f01
Compare
|
@Roasbeef ptal |
halseth
left a comment
There was a problem hiding this comment.
Looks more or less good to me, just a few comments.
routing/router.go
Outdated
There was a problem hiding this comment.
This will need to be shuffled around a little bit after reliable payments are in.
There was a problem hiding this comment.
Yes, but as we already merged the main refactoring of router.go some time ago, it indeed won't be much.
There was a problem hiding this comment.
Reverted to using sendPayment for SendToRoute also, to connect better with #2761.
lnrpc/routerrpc/router.proto
Outdated
There was a problem hiding this comment.
It is uint32 in the wire protocol.
lnrpc/routerrpc/router_server.go
Outdated
There was a problem hiding this comment.
No, no error because the update can be optional.
|
ptal @halseth |
Roasbeef
left a comment
There was a problem hiding this comment.
LGTM 🐊
contingent removal of the last commit
|
Debug commit removed |
halseth
left a comment
There was a problem hiding this comment.
Alright, this LGTM now 🔥
Background
Many ideas float around to build functions/algorithms on top of
lnd. For example: rebalancing, probing, routing service, etc. The current way for that kind of scripts to operate is to make calls toSendToRoute.Unfortunately limited error information is returned to the caller.
routerwill keep trying the supplied routes and if none of them works, return aroutes exhaustederror without the real cause. Even if only one route is supplied. This makes it harder for scripts to guess what happened.Implementation details
SendToRoutecall, it would become a list (of routes) in a list (of payments).oneof. This would for example result in the following json:Maybe not the most intuitive representation in json and I am not sure how this is supported in the proto generators for various languages. It also seems that the oneof key cannot be assigned a
json_name.Usage
A new
SendToRouterpc has been implemented in the router sub server. In order to use it,lndneeds to be compiled withtags="routerrpc".The command has not been added to
lncliand is only available on the rpc interface. Seerouter.protofor more information.