-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
channeldb+rpcserver: expose legacy payments as multi-path payments #3499
channeldb+rpcserver: expose legacy payments as multi-path payments #3499
Conversation
24852d6
to
0369eb7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, I really like the limited scope of this PR! Makes it easy to review, and it is a great first step :)
Gave it a high level look, looks more or less good to me, but will need to see it in tandem with upcoming MPP PRs to make sure things fit 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Solid base groundwork towards multi-pathing all the things 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about the PaymentStatus
call in the router sub-server?
5ce2ebc
to
b1db05a
Compare
Last few commits now add the HTLC attempts to I rebased everything over #3442, which also allowed me test that the MPP record is being set properly in the new sendtoroute itests. This actually pointed out a bug in the test where we would send before receiving the node ann, causing us to downgrade to legacy payments for some of the htlcs. That bug has been fixed in #3442, and here we extend the itest with additional checks on the listpayments rpc. |
6b01397
to
36798d3
Compare
f5ee562
to
17b0ef8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is very close, no major comments :)
17b0ef8
to
9a3efd6
Compare
b77b77a
to
4a62ad9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 😱
@@ -192,16 +191,17 @@ 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) (*route.Route, error) { | |||
preimage lntypes.Preimage) (*MPPayment, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: would be nice if these channeldb
changes could get their own commit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i attempted to do so originally, but it ended up causing more code shuffling than it was worth. the extraction code ends up being duplicated and move around, the tests end up double testing various aspects, etc over 4 commits. so i squashed it all into one since it's i found it easier to just look at the whole change
Preliminary step to exposing PaymentPreimage() as a method that can be shared between legacy payments and mutli-path payments.
Prior name is too long XD
This commit modifies the FetchPayment method to return MPPayment structs converted from the legacy on-disk format. This allows us to attach the HTLCs to the events given to clients subscribing to the outcome of an HTLC. This commit also bubbles up to the routerrpc/router_server, by populating HTLCAttempts in the response and extracting the legacy route field from the HTLCAttempts.
4a62ad9
to
063f24f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Only wondering how relevant this change is now that we aim for single shot mpp first?
case htlc.Failure != nil && result.FailureReason == | ||
channeldb.FailureReasonPaymentDetails: | ||
|
||
legacyRoute = &htlc.Route |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this better than just an if
statement? Or at least use fallthrough
?
Route route.Route | ||
|
||
// AttemptTime is the time at which this HTLC was attempted. | ||
AttemptTime time.Time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This field doesn't seem to be set at all in this pr. Remove and introduce in the follow up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed offline, proceeding in parallel with single shot mpp
Builds on #3442
This PR extends the
ListPayments
,RouterRPC.SendPayment
, andRouterRPC.TrackPayment
to include an experimental field for displaying HTLC attempts for a given payment. This will us to display multiple HTLCs when MPP is fully integrated. Legacy payments will have at most one attempt, and we simply convert them into a more genericMPPayment
struct after loading from disk.In the future we will perform a migration to convert the legacy on-disk format into real MPP payments on disk, but this allows us to fleshing out the API before the internal work is completed.