Skip to content

lnrpc: structured SendToRoute failure reporting#1662

Merged
joostjager merged 4 commits intolightningnetwork:masterfrom
joostjager:raw
May 15, 2019
Merged

lnrpc: structured SendToRoute failure reporting#1662
joostjager merged 4 commits intolightningnetwork:masterfrom
joostjager:raw

Conversation

@joostjager
Copy link
Contributor

@joostjager joostjager commented Jul 31, 2018

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 to SendToRoute.
Unfortunately limited error information is returned to the caller. router will keep trying the supplied routes and if none of them works, return a routes exhausted error without the real cause. Even if only one route is supplied. This makes it harder for scripts to guess what happened.

Implementation details

  • In order to keep it simple, the option to pass in multiple routes is removed. Only a single route per payment is allowed. If multiple routes need to be tried (with or without waiting for the result), they can still be passed in one by one. Otherwise, to get a proper error result for every route in a list of routes, the result object should also need to become a list. In the streaming version of the SendToRoute call, it would become a list (of routes) in a list (of payments).
  • Structured error information is represented as a (flat) list of properties. The alternative would be to use protobuf oneof. This would for example result in the following json:
{
    "payment_error": "UnknownPaymentHash",
    "StructuredResult": {
        "FailUnknownPaymentHash": {}
    }
}

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 SendToRoute rpc has been implemented in the router sub server. In order to use it, lnd needs to be compiled with tags="routerrpc".

The command has not been added to lncli and is only available on the rpc interface. See router.proto for more information.

@joostjager joostjager force-pushed the raw branch 2 times, most recently from 15be4a3 to e0d8f80 Compare August 2, 2018 13:18
@joostjager joostjager changed the title Raw SendToRoute RPC lnrpc: allow pubkey in SendToRoute and better failure reporting Aug 2, 2018
@joostjager joostjager force-pushed the raw branch 2 times, most recently from 30e785a to 7602d53 Compare August 9, 2018 15:46
@joostjager
Copy link
Contributor Author

PR is ready for a first pass review

@joostjager joostjager force-pushed the raw branch 2 times, most recently from 1bba17e to bfac456 Compare August 9, 2018 17:38
@Roasbeef Roasbeef added enhancement Improvements to existing features / behaviour rpc Related to the RPC interface onion routing P3 might get fixed, nice to have labels Aug 14, 2018
@Roasbeef Roasbeef added this to the 0.6 milestone Aug 17, 2018
@joostjager joostjager changed the title lnrpc: allow pubkey in SendToRoute and better failure reporting lnrpc: better payment failure reporting Sep 20, 2018
@Roasbeef Roasbeef requested review from halseth and removed request for halseth October 16, 2018 18:52
@joostjager joostjager force-pushed the raw branch 2 times, most recently from f0ceaf6 to cb1dc9b Compare October 29, 2018 10:20
lnd_test.go Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO should be carried out before this is merged in.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the flags here? Aren't they already contained in the channel update?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the outgoing or incoming CLTV expiry for that hop?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment above

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the field as defined in the lightning spec.

lnrpc/rpc.proto Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar q here: outgoing or incoming?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could add a suffix like _pubkey_bytes, just to clarify what the opaque bytes represent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to expose the sig on the RPC level? As could say the client already fully trusts the server itself.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like the signatures, for data portability

@esneider
Copy link
Contributor

esneider commented May 1, 2019

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.

@joostjager
Copy link
Contributor Author

@esneider The plan is to move ahead with this after the release of 0.6.1, as it contains a breaking change.

@joostjager joostjager force-pushed the raw branch 2 times, most recently from 4f9207c to e498f01 Compare May 6, 2019 19:28
@joostjager
Copy link
Contributor Author

@Roasbeef @halseth ptal

@cfromknecht cfromknecht added this to the 0.7 milestone May 7, 2019
@joostjager
Copy link
Contributor Author

@Roasbeef ptal

Copy link
Contributor

@halseth halseth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks more or less good to me, just a few comments.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will need to be shuffled around a little bit after reliable payments are in.

Copy link
Contributor Author

@joostjager joostjager May 13, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but as we already merged the main refactoring of router.go some time ago, it indeed won't be much.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverted to using sendPayment for SendToRoute also, to connect better with #2761.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uint64?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is uint32 in the wire protocol.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

error case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, no error because the update can be optional.

@joostjager
Copy link
Contributor Author

ptal @halseth

Copy link
Member

@Roasbeef Roasbeef left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🐊

contingent removal of the last commit

@joostjager
Copy link
Contributor Author

Debug commit removed

Copy link
Contributor

@halseth halseth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, this LGTM now 🔥

@joostjager joostjager merged commit 863bf2f into lightningnetwork:master May 15, 2019
@joostjager joostjager deleted the raw branch May 15, 2019 12:39
@joostjager joostjager changed the title lnrpc: better payment failure reporting lnrpc: structured SendToRoute failure reporting May 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Improvements to existing features / behaviour onion routing P3 might get fixed, nice to have rpc Related to the RPC interface

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants