routerrpc: async payment rpc #2973

joostjager · 2019-04-18T14:01:52Z

This PR adds a new SendPayment payment call to the routerrpc sub server. Notable changes:

Configurable payment timeout (this is not to "cancel" htlcs in flight, which is impossible, but controls what the point is after which a new payment attempt isn't started anymore)
Fee limit can only be specified as an absolute value. There is no default anymore. Specifying a value of zero means that no fees may be paid. In that case, only a payment to a direct peer would succeed.
Only payment level failures are reported. This is currently limited to timeout and no_routes, but will be extended in a follow up pr routerrpc: add more failure reasons and route hints #3156. The goal is to report terminal failures like payment_hash_unknown, but not to expose the result of the last payment attempt anymore.

In addition to that, a new rpc call TrackPayment is added. Using TrackPayment an in-flight payment can be picked up after the rpc connection was lost on SendPayment. When #2762 is merged, this also allows picking up payments after a restart of lnd.

Roasbeef · 2019-04-30T00:46:44Z

Shouldn't this be branched off of #2761?

lnrpc/routerrpc/router_backend.go

routing/router.go

lnrpc/routerrpc/router.proto

lnrpc/routerrpc/router_backend.go

cmd/lncli/commands.go

lnrpc/routerrpc/router_server.go

joostjager · 2019-04-30T07:45:48Z

Shouldn't this be branched off of #2761?

Yes, this is still wip. Should have added [wip] to the title.

Roasbeef · 2019-05-27T23:47:46Z

Can be rebased now that #2761 is in.

halseth

Awesome to see the latest changes! It was right to move subscription handling into routing by moving the ControlTower interface there; the separation is clean 👍

I also like the new APIs, they are easy to reason about.

lntypes/hash.go

routing/control_tower.go

halseth · 2019-05-30T10:59:16Z

routing/control_tower.go

+	// succeeded, new subscriber is registered and will immediately receive
+	// the succeeded status, this function sends out the succeeded
+	// notification again to the same subscriber.
+	p.hashMutex.Lock(string(paymentHash[:]))


looks like lock can acquired after DB transaction is over.

The reason the lock needs to be acquired before the db transaction is to prevent a new subscription happening after the db transaction, but before notifyFinalEvent, as is described in the comment above. Maybe I misunderstand you suggestion?

From reading the comment that sounds alright though?

Payment status is updated to succeeded, new subscriber comes in and (acquire lock) retrieves succeed status and sends notification (release lock), this function (acquire lock) finds no one to send notification to (release lock).

Or is there another order of actions that require us to hold it while we update the DB?

Updated code to only use a global lock. It indeed seems to be sufficient.

routing/control_tower.go

lnrpc/routerrpc/router_server.go

rpcserver.go

cmd/lncli/commands.go

joostjager · 2019-05-30T14:25:46Z

@halseth ptal

halseth

LGTM after removal pf last commit 👍

routing/control_tower.go

lnrpc/routerrpc/router.proto

halseth · 2019-06-03T12:35:25Z

lnrpc/routerrpc/router_server.go

 	if err != nil {
+		log.Debugf("SendPayment async result for hash %x: %v",


Fixed using different log level for expected and unexpected errors.

cmd/lncli/commands.go

joostjager · 2019-06-03T22:04:24Z

Brought back the payment update stream and the IN_FLIGHT payment state.

ptal @halseth @Roasbeef

halseth

LGTM 🔥

halseth · 2019-06-04T06:18:49Z

channeldb/payment_control.go

@@ -187,9 +192,12 @@ func (p *PaymentControl) RegisterAttempt(paymentHash lntypes.Hash,
 // duplicate payments to the same payment hash. The provided preimage is
 // atomically saved to the DB for record keeping.
 func (p *PaymentControl) Success(paymentHash lntypes.Hash,
-	preimage lntypes.Preimage) error {
+	preimage lntypes.Preimage) (*route.Route, error) {


To avoid having to do this change, one could instead provinde the route as a param to the Success method in the routing ControlTower.

I am not sure if that is better. It puts a new requirement on the caller of ControlTower.

halseth · 2019-06-04T06:24:23Z

routing/control_tower.go

+			p.subscribers[paymentHash], c,
+		)
+
+		return true, c, nil


Ok, this is much better now that we don't have to return this from the DB.

It isn't new, I just restored code that I had previously. Do you mean it is better because the bool isn't set in the db tx?

cfromknecht

LGTM 💯not blocking, but we have been trying to remove all go-errors imports, and just use the std errors package. sometimes editors will mistakenly add that as the import automatically, since it is used in the integration tests to wrap errors.

routing/control_tower.go

This commit lifts default setting up to the rpc server level, in line with other payment defaults.

Add missing parameters to routerrpc version of SendPayment.

This commit creates an empty shall for control tower in the routing package. It is a preparation for adding event notification.

Allows other sub-systems to subscribe to payment success and fail events.

Modify the routerrpc SendPayment api to asynchronous. This allows callers to pick up a payment after the rpc connection was lost or lnd was restarted.

This commit prepares lncli for moving over to routerrpc payment calls.

joostjager force-pushed the newer-payment-rpc branch 3 times, most recently from 3aee088 to 25bc701 Compare April 18, 2019 14:12

Roasbeef added this to the 0.7 milestone Apr 18, 2019

Roasbeef requested a review from halseth April 18, 2019 23:30

Roasbeef added gRPC incomplete WIP PR, not fully finalized, but light review possible payments Related to invoices/payments routing labels Apr 20, 2019

joostjager mentioned this pull request Apr 27, 2019

routerrpc: share payment parsing code from main rpc #2821

Closed

Roasbeef reviewed Apr 30, 2019

View reviewed changes

joostjager changed the title ~~routerrpc: new payment rpc~~ routerrpc: new payment rpc [wip] Apr 30, 2019

joostjager force-pushed the newer-payment-rpc branch 8 times, most recently from ecfdf21 to 17a98d4 Compare May 3, 2019 07:29

joostjager force-pushed the newer-payment-rpc branch 7 times, most recently from ed4fd68 to 3a60e31 Compare May 28, 2019 11:45

halseth suggested changes May 30, 2019

View reviewed changes

joostjager force-pushed the newer-payment-rpc branch from 9d8603b to 88dca29 Compare May 30, 2019 14:25

joostjager force-pushed the newer-payment-rpc branch 3 times, most recently from d9745ed to 9e51fac Compare May 30, 2019 21:23

halseth approved these changes Jun 3, 2019

View reviewed changes

joostjager force-pushed the newer-payment-rpc branch 5 times, most recently from 71f1c03 to 74e4574 Compare June 3, 2019 22:03

halseth approved these changes Jun 4, 2019

View reviewed changes

halseth mentioned this pull request Jun 4, 2019

[trivial] Merge control tower with payments.go #3124

Closed

joostjager mentioned this pull request Jun 4, 2019

routerrpc: add more failure reasons and route hints #3156

Merged

cfromknecht approved these changes Jun 5, 2019

View reviewed changes

routing/control_tower.go Outdated Show resolved Hide resolved

joostjager force-pushed the newer-payment-rpc branch from 74e4574 to 0f86c71 Compare June 5, 2019 06:52

joostjager added 9 commits June 5, 2019 12:41

lntypes: add ZeroHash

afd8676

routing: move default cltv assignment out of router

19d5f8f

This commit lifts default setting up to the rpc server level, in line with other payment defaults.

routerrpc: extend payment request parameters

eb700d3

Add missing parameters to routerrpc version of SendPayment.

channeldb+routing: move control tower interface to routing

87d3207

This commit creates an empty shall for control tower in the routing package. It is a preparation for adding event notification.

channeldb: add subscription to control tower

eb2647e

Allows other sub-systems to subscribe to payment success and fail events.

routing: add SendPaymentAsync to router

07d289c

routerrpc: convert sendpayment to async

f03533c

Modify the routerrpc SendPayment api to asynchronous. This allows callers to pick up a payment after the rpc connection was lost or lnd was restarted.

channeldb: add todo for more detailed failure reasons

2644759

lncli: unify payinvoice and sendpayment code

220c2be

This commit prepares lncli for moving over to routerrpc payment calls.

joostjager force-pushed the newer-payment-rpc branch from 0f86c71 to 220c2be Compare June 5, 2019 10:46

Roasbeef merged commit 880279b into lightningnetwork:master Jun 5, 2019

wbobeirne mentioned this pull request Sep 9, 2019

Joule hangs indefinitely on HodlInvoice payment joule-labs/joule-extension#232

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

routerrpc: async payment rpc #2973

routerrpc: async payment rpc #2973

joostjager commented Apr 18, 2019 •

edited

Loading

Roasbeef commented Apr 30, 2019

joostjager commented Apr 30, 2019

Roasbeef commented May 27, 2019

halseth left a comment

halseth May 30, 2019

joostjager May 30, 2019

halseth May 30, 2019

joostjager May 30, 2019

joostjager commented May 30, 2019

halseth left a comment

halseth Jun 3, 2019

joostjager Jun 3, 2019

joostjager commented Jun 3, 2019

halseth left a comment

halseth Jun 4, 2019

joostjager Jun 4, 2019

halseth Jun 4, 2019

joostjager Jun 4, 2019

cfromknecht left a comment

		if err != nil {
		log.Debugf("SendPayment async result for hash %x: %v",

routerrpc: async payment rpc #2973

routerrpc: async payment rpc #2973

Conversation

joostjager commented Apr 18, 2019 • edited Loading

Roasbeef commented Apr 30, 2019

joostjager commented Apr 30, 2019

Roasbeef commented May 27, 2019

halseth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joostjager commented May 30, 2019

halseth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joostjager commented Jun 3, 2019

halseth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cfromknecht left a comment

Choose a reason for hiding this comment

joostjager commented Apr 18, 2019 •

edited

Loading