Send BroadcastChannelAnnouncements via the broadcast queue

[TheBlueMatt]

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#4437

Written by Claude

[ldk-reviews-bot]

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[TheBlueMatt]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

[ldk-claude-review-bot]

No double space issue in either location. The prior review's nit about "cannot be announced" must have already been fixed or was about a different line.

I have thoroughly reviewed the entire PR diff. The change is clean and correct. No new issues to report beyond what was already covered in prior review.

No issues found.

The core change is sound: BroadcastChannelAnnouncement events are correctly moved from per-peer queues (peer_state.pending_msg_events) to self.pending_broadcast_messages at both emission sites (announcement_signatures handler and block-connection path). Lock ordering is consistent across all access sites. The test reordering in priv_short_conf_tests.rs correctly reflects that per-peer events now come before broadcast events in get_and_clear_pending_msg_events. The debug_assert! additions in the disconnect-retain match are appropriate guards.

No inline comments posted (no new issues found beyond prior review).

[codecov]

Codecov Report

❌ Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.19%. Comparing base (b3a99f6) to head (6da89c2).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	80.95%	3 Missing and 1 partial ⚠️

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 92697 +4 - Misses 12218 12224 +6 + Partials 2626 2624 -2 

Flag	Coverage Δ
tests	86.19% <80.95%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tnull]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

Yes, that might very well be it.

[TheBlueMatt]

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#4437

Written by Claude

[ldk-reviews-bot]

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[TheBlueMatt]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

[ldk-claude-review-bot]

No double space issue in either location. The prior review's nit about "cannot be announced" must have already been fixed or was about a different line.

I have thoroughly reviewed the entire PR diff. The change is clean and correct. No new issues to report beyond what was already covered in prior review.

No issues found.

The core change is sound: BroadcastChannelAnnouncement events are correctly moved from per-peer queues (peer_state.pending_msg_events) to self.pending_broadcast_messages at both emission sites (announcement_signatures handler and block-connection path). Lock ordering is consistent across all access sites. The test reordering in priv_short_conf_tests.rs correctly reflects that per-peer events now come before broadcast events in get_and_clear_pending_msg_events. The debug_assert! additions in the disconnect-retain match are appropriate guards.

No inline comments posted (no new issues found beyond prior review).

[codecov]

Codecov Report

❌ Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.19%. Comparing base (b3a99f6) to head (6da89c2).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	80.95%	3 Missing and 1 partial ⚠️

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 92697 +4 - Misses 12218 12224 +6 + Partials 2626 2624 -2 

Flag	Coverage Δ
tests	86.19% <80.95%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tnull]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

Yes, that might very well be it.

[TheBlueMatt]

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#4437

Written by Claude

[ldk-reviews-bot]

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[TheBlueMatt]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

[ldk-claude-review-bot]

No double space issue in either location. The prior review's nit about "cannot be announced" must have already been fixed or was about a different line.

I have thoroughly reviewed the entire PR diff. The change is clean and correct. No new issues to report beyond what was already covered in prior review.

No issues found.

The core change is sound: BroadcastChannelAnnouncement events are correctly moved from per-peer queues (peer_state.pending_msg_events) to self.pending_broadcast_messages at both emission sites (announcement_signatures handler and block-connection path). Lock ordering is consistent across all access sites. The test reordering in priv_short_conf_tests.rs correctly reflects that per-peer events now come before broadcast events in get_and_clear_pending_msg_events. The debug_assert! additions in the disconnect-retain match are appropriate guards.

No inline comments posted (no new issues found beyond prior review).

[codecov]

Codecov Report

❌ Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.19%. Comparing base (b3a99f6) to head (6da89c2).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	80.95%	3 Missing and 1 partial ⚠️

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 92697 +4 - Misses 12218 12224 +6 + Partials 2626 2624 -2 

Flag	Coverage Δ
tests	86.19% <80.95%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tnull]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

Yes, that might very well be it.

[TheBlueMatt]

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#4437

Written by Claude

[ldk-reviews-bot]

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[TheBlueMatt]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

[ldk-claude-review-bot]

No double space issue in either location. The prior review's nit about "cannot be announced" must have already been fixed or was about a different line.

I have thoroughly reviewed the entire PR diff. The change is clean and correct. No new issues to report beyond what was already covered in prior review.

No issues found.

The core change is sound: BroadcastChannelAnnouncement events are correctly moved from per-peer queues (peer_state.pending_msg_events) to self.pending_broadcast_messages at both emission sites (announcement_signatures handler and block-connection path). Lock ordering is consistent across all access sites. The test reordering in priv_short_conf_tests.rs correctly reflects that per-peer events now come before broadcast events in get_and_clear_pending_msg_events. The debug_assert! additions in the disconnect-retain match are appropriate guards.

No inline comments posted (no new issues found beyond prior review).

[codecov]

Codecov Report

❌ Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.19%. Comparing base (b3a99f6) to head (6da89c2).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	80.95%	3 Missing and 1 partial ⚠️

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 92697 +4 - Misses 12218 12224 +6 + Partials 2626 2624 -2 

Flag	Coverage Δ
tests	86.19% <80.95%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tnull]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

Yes, that might very well be it.

[TheBlueMatt]

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#4437

Written by Claude

[ldk-reviews-bot]

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[TheBlueMatt]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

[ldk-claude-review-bot]

No double space issue in either location. The prior review's nit about "cannot be announced" must have already been fixed or was about a different line.

I have thoroughly reviewed the entire PR diff. The change is clean and correct. No new issues to report beyond what was already covered in prior review.

No issues found.

The core change is sound: BroadcastChannelAnnouncement events are correctly moved from per-peer queues (peer_state.pending_msg_events) to self.pending_broadcast_messages at both emission sites (announcement_signatures handler and block-connection path). Lock ordering is consistent across all access sites. The test reordering in priv_short_conf_tests.rs correctly reflects that per-peer events now come before broadcast events in get_and_clear_pending_msg_events. The debug_assert! additions in the disconnect-retain match are appropriate guards.

No inline comments posted (no new issues found beyond prior review).

[codecov]

Codecov Report

❌ Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.19%. Comparing base (b3a99f6) to head (6da89c2).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	80.95%	3 Missing and 1 partial ⚠️

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 92697 +4 - Misses 12218 12224 +6 + Partials 2626 2624 -2 

Flag	Coverage Δ
tests	86.19% <80.95%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tnull]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

Yes, that might very well be it.

[TheBlueMatt]

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#4437

Written by Claude

[ldk-reviews-bot]

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[TheBlueMatt]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

[ldk-claude-review-bot]

No double space issue in either location. The prior review's nit about "cannot be announced" must have already been fixed or was about a different line.

I have thoroughly reviewed the entire PR diff. The change is clean and correct. No new issues to report beyond what was already covered in prior review.

No issues found.

The core change is sound: BroadcastChannelAnnouncement events are correctly moved from per-peer queues (peer_state.pending_msg_events) to self.pending_broadcast_messages at both emission sites (announcement_signatures handler and block-connection path). Lock ordering is consistent across all access sites. The test reordering in priv_short_conf_tests.rs correctly reflects that per-peer events now come before broadcast events in get_and_clear_pending_msg_events. The debug_assert! additions in the disconnect-retain match are appropriate guards.

No inline comments posted (no new issues found beyond prior review).

[codecov]

Codecov Report

❌ Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.19%. Comparing base (b3a99f6) to head (6da89c2).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	80.95%	3 Missing and 1 partial ⚠️

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 92697 +4 - Misses 12218 12224 +6 + Partials 2626 2624 -2 

Flag	Coverage Δ
tests	86.19% <80.95%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tnull]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

Yes, that might very well be it.

[TheBlueMatt]

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#4437

Written by Claude

[ldk-reviews-bot]

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[TheBlueMatt]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

[ldk-claude-review-bot]

No double space issue in either location. The prior review's nit about "cannot be announced" must have already been fixed or was about a different line.

I have thoroughly reviewed the entire PR diff. The change is clean and correct. No new issues to report beyond what was already covered in prior review.

No issues found.

The core change is sound: BroadcastChannelAnnouncement events are correctly moved from per-peer queues (peer_state.pending_msg_events) to self.pending_broadcast_messages at both emission sites (announcement_signatures handler and block-connection path). Lock ordering is consistent across all access sites. The test reordering in priv_short_conf_tests.rs correctly reflects that per-peer events now come before broadcast events in get_and_clear_pending_msg_events. The debug_assert! additions in the disconnect-retain match are appropriate guards.

No inline comments posted (no new issues found beyond prior review).

[codecov]

Codecov Report

❌ Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.19%. Comparing base (b3a99f6) to head (6da89c2).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	80.95%	3 Missing and 1 partial ⚠️

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 92697 +4 - Misses 12218 12224 +6 + Partials 2626 2624 -2 

Flag	Coverage Δ
tests	86.19% <80.95%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tnull]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

Yes, that might very well be it.

[TheBlueMatt]

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#4437

Written by Claude

[ldk-reviews-bot]

I've assigned @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[TheBlueMatt]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

[ldk-claude-review-bot]

No double space issue in either location. The prior review's nit about "cannot be announced" must have already been fixed or was about a different line.

I have thoroughly reviewed the entire PR diff. The change is clean and correct. No new issues to report beyond what was already covered in prior review.

No issues found.

The core change is sound: BroadcastChannelAnnouncement events are correctly moved from per-peer queues (peer_state.pending_msg_events) to self.pending_broadcast_messages at both emission sites (announcement_signatures handler and block-connection path). Lock ordering is consistent across all access sites. The test reordering in priv_short_conf_tests.rs correctly reflects that per-peer events now come before broadcast events in get_and_clear_pending_msg_events. The debug_assert! additions in the disconnect-retain match are appropriate guards.

No inline comments posted (no new issues found beyond prior review).

[codecov]

Codecov Report

❌ Patch coverage is 80.95238% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.19%. Comparing base (b3a99f6) to head (6da89c2).
⚠️ Report is 7 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	80.95%	3 Missing and 1 partial ⚠️

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 92697 +4 - Misses 12218 12224 +6 + Partials 2626 2624 -2 

Flag	Coverage Δ
tests	86.19% <80.95%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tnull]

cc @tankyleo@tnull does this potentially explain the issues y'all saw?

Yes, that might very well be it.