-
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
routing: include htlc amount in bandwidth hint queries #5512
routing: include htlc amount in bandwidth hint queries #5512
Conversation
3e68f16
to
1ae8b33
Compare
itests failing, removing request for review while I look into whether it's flakes vs this change |
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.
Completed an initial pass, looks like the changes didn't turn out to be too elaborate which is nice. I took a look at the itest failures, and don't think they're directly related to this PR. Would wager a new rebase (with all the recent flakes that have been hunted) would eliminate a lot of the failures we're seeing right now for this PR.
routing/bandwidth.go
Outdated
edgeInfo *channeldb.ChannelEdgeInfo, | ||
_, _ *channeldb.ChannelEdgePolicy) error { | ||
|
||
manager.localChans[edgeInfo.ChannelID] = edgeInfo |
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.
Do we actually need the entire edge info here? Given it can become out of date after a channel update, or do we only care about the channel ID itself?
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.
Do you mean replace the edgeInfo
with just a balance hint? Could do that, this is just blind copy-fu from the old impl.
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.
Yeah, I mean just tracking the minimal amount of information here given that's all we need, and everything else can possibly become inconsistent shortly after we start up.
routing/bandwidth.go
Outdated
@@ -13,11 +13,20 @@ type bandwidthHints interface { | |||
// channel and a bool indicating whether the channel hint was found. | |||
// If the channel is unavailable, a zero amount is returned. | |||
availableChanBandwidth(channelID uint64) (lnwire.MilliSatoshi, bool) | |||
|
|||
// availableHtlcBandwidth returns the total available bandwidth that |
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.
Do we actually need both of these? (still getting through the diff)
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.
Could def cut down and just have one method that takes a pointer to amount (if present), I thought it was nicer from the caller's perspective to not need to care about that detail.
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.
Seems duplicate here. I think what we want here,
- know the current bandwidth
- check if our bandwidth can carry the amount
Step 2 is implemented in both getPolicyLocal
and MayAddOutgoingHtlc
, sort redundant?
1ae8b33
to
d90e894
Compare
a6bdb8a
to
98ca67a
Compare
routing/payment_lifecycle_test.go
Outdated
@@ -472,9 +472,6 @@ func testPaymentLifecycle(t *testing.T, test paymentLifecycleTestCase, | |||
Payer: payer, | |||
ChannelPruneExpiry: time.Hour * 24, | |||
GraphPruneInterval: time.Hour * 2, | |||
QueryBandwidth: func(e *channeldb.ChannelEdgeInfo) lnwire.MilliSatoshi { |
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.
Should we have QueryBandwidth
in the Config
?
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.
Interested in your opinion here. The QueryBandwidth
(now replaced with GetLink
) function isn't actually used in these tests. I'm usually in favor of not creating unnecessary mocks. If the test is ever updated to need the function, it'll panic and it will be very apparent where the change needs to be made.
routing/bandwidth.go
Outdated
@@ -13,11 +13,20 @@ type bandwidthHints interface { | |||
// channel and a bool indicating whether the channel hint was found. | |||
// If the channel is unavailable, a zero amount is returned. | |||
availableChanBandwidth(channelID uint64) (lnwire.MilliSatoshi, bool) | |||
|
|||
// availableHtlcBandwidth returns the total available bandwidth that |
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.
Seems duplicate here. I think what we want here,
- know the current bandwidth
- check if our bandwidth can carry the amount
Step 2 is implemented in both getPolicyLocal
and MayAddOutgoingHtlc
, sort redundant?
0c90d64
to
9b9eb95
Compare
9b9eb95
to
840ff7e
Compare
Visit https://dashboard.github.orijtech.com?back=0&pr=5512&remote=true&repo=carlaKC%2Flnd to see benchmark details. |
840ff7e
to
c1b80fa
Compare
Rebase now to see if those flakes have been resolved? |
9acb955
to
85005a2
Compare
Much greener after rebase! Failure look unrelated, I think there may be an issue w/ the |
This one?
That was recently added by @Crypt-iQ when fixing some of the dust stuff |
85005a2
to
fee093a
Compare
Changes looking good, glad all the flakes are gone. Got a few nits and, is there an easy way for us to add itest for this change? |
fee093a
to
8876b57
Compare
Pass htlc amount down to the channel so that we don't need to rely on minHtlc (and pad it when the channel sets a 0 min htlc). Update test to just check some sane values since we're no longer relying on minHtlc amount at all.
We already have itest coverage for the validation in |
8876b57
to
721ef7d
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👍
as for itest coverage for the specific change of passing the htlc amount in rather than using minimum htlc amount, I think that the unit tests are sufficient?
I'd say they are different. Imo we should have a unit test to check the function is working within the package and an itest to check the function fits the whole system, which are very different tests. Nonblocking tho as the current change doesn't break the itest for MayAddOutgoingHtlc
.
Also the itest timeouts would be fixed by #5845 I think.
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 🌤
case lc.channelState.LocalChanCfg.MinHTLC != 0: | ||
mockHtlcAmt = lc.channelState.LocalChanCfg.MinHTLC | ||
|
||
// As a last resort, we just add a non-zero amount. |
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 PR bubbles our htlc amount all the way down to
MayAddOutgoingHtlc
, implementing the full fix for #5468 (replacing the temporary fix introduced in #5478 to account for nodes that set a 0minHtlc
).