Invoice round robin #3913
Invoice round robin #3913
Conversation
ZmnSCPxj
force-pushed
the
invoice-round-robin
branch
4 times, most recently
from
7492fab
to
5ed2b18
Compare
ZmnSCPxj
force-pushed
the
invoice-round-robin
branch
3 times, most recently
from
abf9504
to
984268f
Compare
|
The errors occurring, while they occur in |
ZmnSCPxj
force-pushed
the
invoice-round-robin
branch
from
984268f
to
c3f4c45
Compare
|
Disabled the test at |
|
Added the routehint randomization suggested here: #3914 (comment) My initial non-exhaustive tests suggest it improves the success rate and speed of A proper round-robin allocation of routehints would, I think, improve this even more, but the random-base idea is "good enough" in practice IMO and is very very simple to implement. |
ZmnSCPxj
force-pushed
the
invoice-round-robin
branch
from
917bd84
to
bd392e8
Compare
ZmnSCPxj
force-pushed
the
invoice-round-robin
branch
from
bd392e8
to
4a9e570
Compare
|
Rebased now that #3914 is on master. |
… method to LightningNode, for when you want to Thanos your channels.
Changelog-Changed: We now make MPP-aware routehints in invoices.
This improves the success rate of `test_mpp_interference_2`, though still not quite up to the level that we can remove `@flaky` from it.
ZmnSCPxj
force-pushed
the
invoice-round-robin
branch
from
4a9e570
to
6972e1f
Compare
|
Rebased again. |
| @@ -3354,3 +3354,100 @@ def pay(l1, inv): | |||
|
|
|||
| # pay command should complete without error | |||
| fut.result(TIMEOUT) | |||
|
|
|||
|
|
|||
| @unittest.skipIf(VALGRIND, "runs 7 nodes") | |||
There was a problem hiding this comment.
It's enough to mark it as slow (as you do below) which turns off VALGRIND if SLOW_MACHINE.
Otherwise this test will never run under CI, since we test VALGRIND=1 DEVELOPER=1 and VALGRIND=0 DEVELOPER=0...
|
I like this, just want to combine some logic. We measure the incoming capacity both here and in the listpeers code (which does a more thorough job), so we should combine those. I also dislike the duplication between the mpp and non-mpp, so I'll refactor that as well while I'm at it. Just waiting for Travis, which I had to kick... |
|
Ack 6972e1f |
This implements part of my suggestions in #3894.
The drawback is that unpublished nodes with this commit could potentially be harder to pay by other implementations that do not have any MPP at all yet.
This change basically embraces MPP and holds onto it tight and whispers lovingly into its ears "I want the whole world to have MPP". On the other hand it does show that our MPP impl seems to be working nicely enough.
It was implementing this that revealed #3908 , if you are curious. Yet another reason to abolish unpublished channels....
There is yet another bug in our MPP that this code also reveals, which is basically that if we get a blockheight disagreement between payee and payer, we are too aggressive with advancing the routehint pointer. I will make a new test and fix for that latent bug.