-
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: don't set custom amount if manager isn't handling #9502
base: master
Are you sure you want to change the base?
Conversation
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
routing/bandwidth.go
Outdated
// traffic shaper is not handling the channel. In that | ||
// case, we'll just return the original bandwidth and | ||
// no custom amount. | ||
if auxBandwidth.IsNone() { |
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 suggest removing the HTLC amount from the bandwidthResult, because if its not a custom payment we just check for the amount which was passed in I think that's what the channel needs to route at a bare minimum anyways, and if its a normal payment we use the real HTLC amount nevertheless.
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.
No, unfortunately we can't do that. If we're trying to pay an invoice over let's say 500k sats, then that amount is passed in as amount
. In a channel that only has the capacity of 100k sats, we clearly can't send 500k. And with an asset channel, we're not going to, as we're going to convert to assets and will only really send 354 sats. That's why the bandwidth result overwrites the htlcAmount
with 0 (which just means "the minimum amount possible") in case of an asset channel.
What we need to fix here is the behavior for non-asset channels, which is what this commit/PR does.
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.
ahh gottya, so when sending a custom payment the HTLC amount here is not already adjusted for, ok understand.
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.
Correct. This is a first stage to find out what channel(s) are even eligible for carrying the payment. That initial selection, just based on available bandwidth/balance is then used to narrow down the search during the actual pathfinding (no use selecting paths through channels where we know we don't have the required balance).
So the actual conversion of the HTLC into an asset HTLC happens in a next step, after a route has been chosen.
The actual amount that goes on chain is determined here:
lnd/routing/payment_lifecycle.go
Line 773 in 4eea207
result, err := fn.MapOptionZ( |
If there are no firstHopCustomRecords
, then the initial rt.TotalAmount
is returned from the traffic shaper.
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
should test this against LitD
bdb21bc
to
78c8dae
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
type OptionalBandwidth struct { | ||
// IsHandled is true if the external traffic shaper handles the channel. | ||
// If this is false, then the bandwidth value is not applicable. | ||
IsHandled bool |
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.
when does this set to true?
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.
Argh, good catch. Copy/paste mistake. Fixed!
We'll validate all of this with an integration test in litd
. Unfortunately we aren't really set up to test these things properly in unit or integration tests with in lnd
(but probably worth the investment very soon).
To make it more clear whether the external traffic shaper is handling a channel or not, we return an explicit boolean.
78c8dae
to
e490347
Compare
auxBandwidth.WhenSome(func(bandwidth lnwire.MilliSatoshi) { | ||
availableBandwidth = bandwidth | ||
}) | ||
if auxBandwidth.IsHandled && auxBandwidth.Bandwidth.IsSome() { |
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 really need this second arg (auxBandwidth.Bandwidth.IsSome()
), if the some is not set we just pass the check below ?
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, this is super-defensive I guess. More for the reader of the code than the compiler. But can remove if you feel it has the opposite effect, reducing clarity.
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.
ahh ok yeah let's keep it then.
@guggero, remember to re-request review from reviewers when ready |
!lightninglabs-deploy mute |
Avoids overwriting the HTLC amount if the aux bandwidth manager isn't handling the channel.