Send BroadcastChannelAnnouncements via the broadcast queue#4508
Send BroadcastChannelAnnouncements via the broadcast queue#4508TheBlueMatt wants to merge 1 commit intolightningdevkit:mainfrom
Conversation
In 47a3e5c we started asserting that the per-peer message queue was empty when a peer connected to ensure we don't have stale messages sitting around in memory. This turned up an issue for `channel_announcement` messages generated by block connections while a peer was disconnected. Here we push those out through the broadcast message queue rather than the per-peer message queue as there's no reason to tie them to the individual peer anyway, fixing the assertions. This should fix lightningdevkit#4437 Written by Claude
|
I've assigned @wpaulino as a reviewer! |
| update_msg: Some(self.get_channel_update_for_broadcast(chan).unwrap().0), | ||
| }); | ||
| let announcement_msg = try_channel_entry!(self, peer_state, res, chan_entry); | ||
| // Note that announcement_signatures fails if the channel cannot be announced, |
There was a problem hiding this comment.
Nit: double space — "cannot be announced" → "cannot be announced".
| // Note that announcement_signatures fails if the channel cannot be announced, | |
| // Note that announcement_signatures fails if the channel cannot be announced, |
Review SummaryThe core change — moving Inline comments posted
No bugs or security issues foundThe change correctly fixes the scenario described in #4437 where |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4508 +/- ##
==========================================
- Coverage 86.19% 86.19% -0.01%
==========================================
Files 160 160
Lines 107537 107545 +8
Branches 107537 107545 +8
==========================================
+ Hits 92693 92695 +2
- Misses 12218 12225 +7
+ Partials 2626 2625 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
4 participants
In 47a3e5c we started asserting that the per-peer message queue was empty when a peer connected to ensure we don't have stale messages sitting around in memory. This turned up an issue for
channel_announcementmessages generated by block connections while a peer was disconnected.Here we push those out through the broadcast message queue rather than the per-peer message queue as there's no reason to tie them to the individual peer anyway, fixing the assertions.
This should fix #4437
Written by Claude