Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lnrpc: deprecate SendToRoute with more than one route #2521

Merged
merged 2 commits into from Feb 6, 2019

Conversation

joostjager
Copy link
Collaborator

The current SendToRoute RPC call offers the option of passing in multiple routes. Especially in the streaming variant, this makes the structure of the response complicated, because it is double nested (multiple streamed requests each containing multiple routes for each of which a result needs to be reported). The advantage of this in terms of network round trips is negligible, so the proposal is to limit every SendToRoute request to a single route.

@Roasbeef Roasbeef added rpc Related to the RPC interface code health Related to code commenting, refactoring, and other non-behaviour improvements gRPC P3 might get fixed, nice to have labels Jan 21, 2019
halseth
halseth previously approved these changes Jan 22, 2019
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.

I'm fine with doing this change, also something that should be done to the sync methods eventually IMO.

Get this in to v0.6? LGTM 👍

@@ -4072,7 +4070,7 @@ func unmarshallHop(graph *channeldb.ChannelGraph, hop *lnrpc.Hop,

// unmarshallRoute unmarshalls an rpc route. For hops that don't specify a
// pubkey, the channel graph is queried.
func (r *rpcServer) unmarshallRoute(rpcroute *lnrpc.Route,
Copy link
Contributor

Choose a reason for hiding this comment

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

ooh, nice

@Roasbeef Roasbeef added this to the 0.6 milestone Jan 23, 2019
}

var routes []*routing.Route
if len(req.Routes) > 0 {
Copy link
Member

Choose a reason for hiding this comment

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

Why even distinguish these two cases? If the case of the else statement, it completes after a single loop iteration.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I chose not to restrict the Routes field to a single element, but to add a new non-list field Route. Therefore the else construct here.

The intention behind this is to make one change to the interface and not two (first restrict to a single element and then later make it a non-list field).

@joostjager
Copy link
Collaborator Author

ptal @Roasbeef

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 🔌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code health Related to code commenting, refactoring, and other non-behaviour improvements gRPC 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.

None yet

3 participants