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 |
Roasbeef
left a comment
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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.
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.
There was a problem hiding this comment.
Do we actually need both of these? (still getting through the diff)
There was a problem hiding this comment.
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.
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
There was a problem hiding this comment.
Should we have QueryBandwidth in the Config?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
yyforyongyu
left a comment
There was a problem hiding this comment.
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.
| case lc.channelState.LocalChanCfg.MinHTLC != 0: | ||
| mockHtlcAmt = lc.channelState.LocalChanCfg.MinHTLC | ||
|
|
||
| // As a last resort, we just add a non-zero amount. |
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).