htlcswitch+invoices: allow settling invoices via multi-path payments#3415
htlcswitch+invoices: allow settling invoices via multi-path payments#3415joostjager merged 4 commits intolightningnetwork:masterfrom
Conversation
joostjager
changed the title
joostjager
force-pushed
the
mpp
branch
3 times, most recently
from
5f1966a to
45a27a3
Compare
joostjager
force-pushed
the
mpp
branch
2 times, most recently
from
9e0b20f to
a4b9fa2
Compare
joostjager
added
incomplete
cfromknecht
left a comment
cfromknecht
left a comment
There was a problem hiding this comment.
just did a quick pass to refresh my memory of this pr. i know you said don't review, but just leaving some initial comments tho i'm sure the underlying pr has changed a bit
joostjager
changed the title
joostjager
force-pushed
the
mpp
branch
3 times, most recently
from
9c81a17 to
c03862c
Compare
cfromknecht
left a comment
cfromknecht
left a comment
There was a problem hiding this comment.
so far so good, changes coming together :) should be pretty close to being able to do a full e2e!
joostjager
force-pushed
the
mpp
branch
3 times, most recently
from
9a8df74 to
b75c07f
Compare
|
Note to self: don't forget to remove debug commits |
joostjager
force-pushed
the
mpp
branch
2 times, most recently
from
158eafb to
e0295d5
Compare
cfromknecht
left a comment
cfromknecht
left a comment
There was a problem hiding this comment.
did another pass, just one minor nit. is it time to remove debug commits?
joostjager
force-pushed
the
mpp
branch
3 times, most recently
from
c77e8ed to
894850a
Compare
|
debug commits removed |
joostjager
force-pushed
the
mpp
branch
2 times, most recently
from
a68de27 to
a96f9a4
Compare
|
@cfromknecht brought up the mpp timeout failure. Will address that in a follow up in coordination with @carlaKC. Without this error returned, senders that actually support sending multiple shards and interpret this new failure will not function optimally. But seems acceptable for where we are right now. |
halseth
left a comment
halseth
left a comment
There was a problem hiding this comment.
All aboard the mpptrain! 🚂 LGTM
invoices/invoiceregistry.go
Outdated
There was a problem hiding this comment.
Shouldn't we use either signed or unsigned types for block height everywhere?
There was a problem hiding this comment.
Yes, that is inconsistent at the moment. But if you start changing, you will expand into many different areas and also replace one case by the other sometimes.
invoices/clock_test.go
Outdated
There was a problem hiding this comment.
Really nice! May I suggest you to extend clock.Clock interface and use that as a common ground instead? Maybe also move this test clock in that package such that others can use it?
There was a problem hiding this comment.
I don't want to delay this PR with a discussion on where to put that package/file. Given the time those took in past prs I'd rather avoid it (reference class forecasting).
invoices/invoiceregistry_test.go
Outdated
There was a problem hiding this comment.
Looks like the file changed during review. The above comment meant to be here: "I think it's important to test cases where settlement may fail".
There was a problem hiding this comment.
There is a case where the partial payment times out. Which other cases do you mean? Of course the total number of possible test cases is large, but I tried to cover at least the ones that usually occur.
invoices/invoiceregistry.go
Outdated
There was a problem hiding this comment.
Can this ever happen though?
There was a problem hiding this comment.
I don't think so. Perhaps we will do invoice cleanup in the future?
This commit introduces PriorityQueue, which is a general, heap based priority queue, and PriorityQueueItem which is an interface that concrete priority queue items must implement. This implementation is encapsulated, users do not need to use any other package for full functionality. PriorityQueue exports the usual public methids: Push, Pop, Top, Empty and Len. For full documentaton consult the priority_queue.go, for usage: priority_queue_test.go
4 participants
Before this PR, MPP fields in the payload were parsed but not processed. This PR adds processing of those fields in the invoice registry. This means that it is now possible to settle an invoice using multiple partial payments.