Skip to content
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

Merged
merged 3 commits into from
Oct 19, 2021

Conversation

carlaKC
Copy link
Collaborator

@carlaKC carlaKC commented Jul 14, 2021

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 0 minHtlc).

@carlaKC
Copy link
Collaborator Author

carlaKC commented Jul 19, 2021

itests failing, removing request for review while I look into whether it's flakes vs this change

Copy link
Member

@Roasbeef Roasbeef left a 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.

edgeInfo *channeldb.ChannelEdgeInfo,
_, _ *channeldb.ChannelEdgePolicy) error {

manager.localChans[edgeInfo.ChannelID] = edgeInfo
Copy link
Member

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?

Copy link
Collaborator Author

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.

Copy link
Member

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.

@@ -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
Copy link
Member

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)

Copy link
Collaborator Author

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.

Copy link
Collaborator

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,

  1. know the current bandwidth
  2. check if our bandwidth can carry the amount

Step 2 is implemented in both getPolicyLocal and MayAddOutgoingHtlc, sort redundant?

server.go Outdated Show resolved Hide resolved
server.go Outdated Show resolved Hide resolved
@carlaKC carlaKC force-pushed the 5468-amountawarehint branch 2 times, most recently from a6bdb8a to 98ca67a Compare August 24, 2021 13:37
routing/bandwidth.go Outdated Show resolved Hide resolved
routing/bandwidth.go Show resolved Hide resolved
routing/integrated_routing_context_test.go Show resolved Hide resolved
@@ -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 {
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

server.go Outdated Show resolved Hide resolved
htlcswitch/link.go Outdated Show resolved Hide resolved
lnwallet/channel.go Show resolved Hide resolved
lnwallet/channel.go Outdated Show resolved Hide resolved
@@ -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
Copy link
Collaborator

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,

  1. know the current bandwidth
  2. check if our bandwidth can carry the amount

Step 2 is implemented in both getPolicyLocal and MayAddOutgoingHtlc, sort redundant?

lnwallet/channel_test.go Show resolved Hide resolved
@carlaKC carlaKC force-pushed the 5468-amountawarehint branch 2 times, most recently from 0c90d64 to 9b9eb95 Compare August 26, 2021 09:04
@Roasbeef Roasbeef added the P2 should be fixed if one has time label Aug 31, 2021
@orijbot
Copy link

orijbot commented Sep 3, 2021

@carlaKC
Copy link
Collaborator Author

carlaKC commented Sep 3, 2021

Rebased this on #5642 and itest flakes are totally resolved. If we're happy to block this on that merge (don't really see another option), I'll push the rebased version? cc @Roasbeef

@Roasbeef
Copy link
Member

Roasbeef commented Oct 5, 2021

Rebase now to see if those flakes have been resolved?

@carlaKC carlaKC force-pushed the 5468-amountawarehint branch 3 times, most recently from 9acb955 to 85005a2 Compare October 6, 2021 07:58
@carlaKC
Copy link
Collaborator Author

carlaKC commented Oct 7, 2021

Rebase now to see if those flakes have been resolved?

Much greener after rebase! Failure look unrelated, I think there may be an issue w/ the htlcswitch tests rn?

@Roasbeef
Copy link
Member

Roasbeef commented Oct 8, 2021

This one?

    switch_test.go:3486: 
        	Error Trace:	switch_test.go:3486
        	Error:      	Target error should be in err chain:
        	            	expected: "dust threshold exceeded"
        	            	in chain: 
        	Test:       	TestSwitchDustForwarding

That was recently added by @Crypt-iQ when fixing some of the dust stuff

@yyforyongyu
Copy link
Collaborator

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?

routing/bandwidth.go Outdated Show resolved Hide resolved
routing/bandwidth_test.go Outdated Show resolved Hide resolved
server.go Show resolved Hide resolved
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.
@carlaKC
Copy link
Collaborator Author

carlaKC commented Oct 19, 2021

is there an easy way for us to add itest for this change?

We already have itest coverage for the validation in MayAddOutgoingHtlc in "max htlc pathfind", 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?

Copy link
Collaborator

@yyforyongyu yyforyongyu left a 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.

Copy link
Member

@Roasbeef Roasbeef left a 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@Roasbeef Roasbeef merged commit 290b78e into lightningnetwork:master Oct 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug fix P2 should be fixed if one has time routing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants