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.

Sign up for GitHub

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

server.go: add peerChan to peerConnectedListeners in NotifyWhenOnline #6892

Merged
merged 2 commits into from
Sep 21, 2022
Merged

server.go: add peerChan to peerConnectedListeners in NotifyWhenOnline #6892

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2def3fc
server.go: add peerChan to peerConnectedListeners in NotifyWhenOnline
Crypt-iQ Sep 6, 2022
02f7fa9
release-notes: update for 0.15.2
Crypt-iQ Sep 7, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions docs/release-notes/release-notes-0.15.2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,12 @@
(`POST /v1/graph/routes`)](https://github.com/lightningnetwork/lnd/pull/6926)
to make it possible to specify `route_hints` over REST.

## Bug Fixes

* [A bug where LND wouldn't send a ChannelUpdate during a channel open has
been fixed.](https://github.com/lightningnetwork/lnd/pull/6892)

# Contributors (Alphabetical Order)

* Eugene Siegel
* Oliver Gugger
8 changes: 7 additions & 1 deletion server.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3195,7 +3195,13 @@ func (s *server) NotifyWhenOnline(peerKey [33]byte,
select {
case <-peer.ActiveSignal():
case <-peer.QuitSignal():
// The peer quit so we'll just return.
// The peer quit, so we'll add the channel to the slice
// and return.
s.mu.Lock()
s.peerConnectedListeners[pubStr] = append(
Copy link
Member

Choose a reason for hiding this comment

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

Nice catch! I think this might also be affecting reliable direct sends of channel update messages at times.

Copy link
Member

Choose a reason for hiding this comment

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

I think it'd be ideal for us to also add a unit test here. Most of the state here can be pretty easily subbed out (#5700 should make this easier in the future).

So in this case, the test would add a canned peer to peersByPub (which doesn't seem to use the main peer interface rn actually), then fire either of the signals to make it enter this new case. A follow up block would then just call peerInitializer which'll then send the signals as normal.

Thoughts?

Copy link
Collaborator Author

@Crypt-iQ Crypt-iQ Sep 7, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

I don't think this can be done easily - peerInitializer needs a server object and eventually calls p.Start() which requires a channeldb and launches goroutines that require other things like a mocked connection. It would be easier if peersByPub used an interface instead of peer.Brontide which would let us precisely control this. Another issue is that any time peer.Brontide is started successfully, the ActiveSignal is fired on, meaning that this test using peerInitializer will have both the ActiveSignal and the QuitSignal active in that select statement, so it could lead to not exercising the quit logic all the time

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

#5700 doesn't change peersByPub and the other related maps to an interface, but I think that would be the way to go to test this.

Also independent of this bug fix, some of the callsites of NotifyWhenOnline don't retry if a later call to SendMessage failed. This is problematic since the peer could have gone down by the time you end up sending the message.

s.peerConnectedListeners[pubStr], peerChan,
)
s.mu.Unlock()
return
}

Expand Down