-
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
lncli: remote peer alias in listchannels
#7322
lncli: remote peer alias in listchannels
#7322
Conversation
ac91882
to
a675f76
Compare
a675f76
to
321177a
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.
Nice feature, thanks a lot!
Looks like there are a couple of failures in the linter and unit tests. But other than that, looks pretty good to me.
321177a
to
228a617
Compare
@hieblmi, remember to re-request review from reviewers when ready |
228a617
to
a65abe0
Compare
Thanks for the review @guggero, I missed the test case errors but fixed them now and also addressed your nits. |
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.
Very nice, LGTM 🎉
lntemp/harness_assertion.go
Outdated
@@ -345,12 +345,15 @@ func (h *HarnessTest) AssertChannelExists(hn *node.HarnessNode, | |||
// findChannel tries to find a target channel in the node using the given | |||
// channel point. | |||
func (h *HarnessTest) findChannel(hn *node.HarnessNode, | |||
chanPoint *lnrpc.ChannelPoint) (*lnrpc.Channel, error) { | |||
chanPoint *lnrpc.ChannelPoint, peerAliasLookup bool) (*lnrpc.Channel, |
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.
We could use a variadic argument list with functional options to avoid needing to add the new parameter everywhere. And then just use withPeerLookup()
if you want to enable it. Example, in case it's not clear what I mean: https://github.com/lightninglabs/lndclient/blob/master/lightning_client.go#L2786
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.
Thanks for the hint, this looks a little cleaner now.
1b61ae2
to
f51aa75
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.
Great work, thank you!
One final nit in the itest, otherwise looks good to me 🎉
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 after Oli's comment about options has been addressed :)
Just need to update the release notes entry with the correct link too 🙏
7d4c275
to
66cf6d8
Compare
1e1f145
to
d2c9af5
Compare
|
d9104cc
to
cdd8b14
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 🎉
@saubyk given RC1 was just cut, can we still get this in for 0.16?
itest/lnd_misc_test.go
Outdated
opts := []lntest.ListChannelOption{lntest.WithPeerAliasLookup()} | ||
|
||
aliceChannelWithAlias := ht.QueryChannelByChanPoint( | ||
alice, chanPoint, opts..., |
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.
The nice thing about these options is, you can just do alice, chanPoint, lntest.WithPeerAliasLookup()
here. But non-blocking, since the diff is now much cleaner already.
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.
Changed it here and below. I thought having the opts
field might come in handy in the future to add options to it. But it isn't very likely that we add additional options right here.
1fa7d78
to
313983f
Compare
We can, given that it's good to go. |
If there is an alias lookup problem for a peer it will return |
Are you pointing to the redundant wording of the error message? Should |
No, I think it's about returning the error vs. logging the error. As was discussed in #7001 (comment)... |
Oh right, initially I thought of returning an empty alias if an error during the lookup happens so that we don't interrupt it as it is flagged now. |
I tried it in a regtest scenario and didn't have no alias on purpose but it maybe can happen while the graph is still syncing? |
Okay, I guess we should just ignore (and not even log) the errors related to fetching the peer alias. If a user wants to know why an alias isn't showing, they can do |
@guggero I will submit it in a bit. |
Implements feature #6994, continuation of PR #7006
This PR introduces a
peer_alias
field for channels that are retrieved by theListChannels
RPC. By default the peer alias lookup is disabled to avoid degradation of the performance of existing clients. However it can be enabled by passing a new flagpeerAliasLookup
toListChannels
. For conveniencelncli listchannels
enables the lookup by default but it can be disabled by a new flagskip_peer_alias_lookup
.