Skip to content

Additional closing cleanups post-#3881 #3899

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

Merged
merged 5 commits into from
Jul 23, 2025

Conversation

TheBlueMatt
Copy link
Collaborator

I had really hoped to spend some time moving some of the monitor completion and closure logic out of macros (as I fear they are a nontrivial portion of our compile time), but sadly I just really don't have the time. So instead here's the few additional small things I wanted to get out of the way.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jun 28, 2025

👋 Thanks for assigning @tnull 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.

Copy link

codecov bot commented Jun 28, 2025

Codecov Report

Attention: Patch coverage is 86.88525% with 8 lines in your changes missing coverage. Please review.

Project coverage is 89.00%. Comparing base (4e4f128) to head (0b3ba85).
Report is 8 commits behind head on main.

Files with missing lines Patch % Lines
lightning/src/ln/channelmanager.rs 84.61% 7 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3899      +/-   ##
==========================================
- Coverage   89.01%   89.00%   -0.02%     
==========================================
  Files         168      168              
  Lines      121784   121799      +15     
  Branches   121784   121799      +15     
==========================================
- Hits       108411   108407       -4     
- Misses      10966    10983      +17     
- Partials     2407     2409       +2     
Flag Coverage Δ
fuzzing 22.68% <6.66%> (+<0.01%) ⬆️
tests 88.82% <86.88%> (-0.02%) ⬇️

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 tnull requested review from tnull and removed request for joostjager June 30, 2025 13:17
Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

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

Will take a closer look soon, but, FYI, CI is unhappy.

@TheBlueMatt
Copy link
Collaborator Author

Yea, realized that but will probably fix after #3881

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

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

This needs a rebase now that #3881 has been merged.

@TheBlueMatt TheBlueMatt force-pushed the 2025-06-close-cleanup branch 2 times, most recently from 853bdfc to a099c02 Compare July 14, 2025 17:35
@TheBlueMatt
Copy link
Collaborator Author

Squashed and fixed rustfmt.

@TheBlueMatt TheBlueMatt force-pushed the 2025-06-close-cleanup branch from a099c02 to afc42ab Compare July 14, 2025 18:05
tnull
tnull previously approved these changes Jul 15, 2025
Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

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

Changes by themselves LGTM.

Once this is land I'll need to see how to proceed with the simple-close flow.

@tnull tnull requested a review from wpaulino July 15, 2025 09:31
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@TheBlueMatt TheBlueMatt added the weekly goal Someone wants to land this this week label Jul 17, 2025
@TheBlueMatt TheBlueMatt self-assigned this Jul 17, 2025
@TheBlueMatt TheBlueMatt force-pushed the 2025-06-close-cleanup branch from afc42ab to 59bf265 Compare July 17, 2025 19:06
@TheBlueMatt
Copy link
Collaborator Author

Rebased.

// We're done with this channel, we've got a signed closing transaction and
// will send the closing_signed back to the remote peer upon return. This
// also implies there are no pending HTLCs left on the channel, so we can
// fully delete it from tracking (the channel monitor is still around to
// watch for old state broadcasts)!
locked_close_channel!(self, peer_state, chan, close_res, FUNDED);
(Some(tx), Some(chan_entry.remove()), Some(close_res))
let (_, err) = convert_channel_err!(self, peer_state, close_res, chan, &msg.channel_id, COOP_CLOSED);
Copy link
Contributor

Choose a reason for hiding this comment

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

I find it odd that coop close gets classified as an error when it's something both nodes agreed upon, but I guess it's too late to really do anything about it

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I mean I can add a new, wrapping, macro to give it a new name, or rename convert_channel_err?

@TheBlueMatt TheBlueMatt force-pushed the 2025-06-close-cleanup branch 2 times, most recently from 2d5a81d to 731657b Compare July 20, 2025 12:27
@TheBlueMatt TheBlueMatt requested review from tnull and wpaulino July 20, 2025 12:27
Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

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

Fixups LGTM, feel free to squash from my side.

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@TheBlueMatt TheBlueMatt force-pushed the 2025-06-close-cleanup branch from 731657b to fc69f66 Compare July 22, 2025 15:29
@TheBlueMatt
Copy link
Collaborator Author

Squashed without further changes.

wpaulino
wpaulino previously approved these changes Jul 22, 2025
Copy link
Contributor

@wpaulino wpaulino left a comment

Choose a reason for hiding this comment

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

Would still like to see the closing logs cleaned up a bit more, but it doesn't have to block this

Our coop close methods `Channel::maybe_propose_closing_signed` and
`Channel::closing_signed` may return a `Transaction` to broadcast
as well as a `ShutdownResult` to provide the post-shutdown
handling fields. However, it only does either both of them or
neither - we only and always broadcast when we're done closing.

Here we tweak the return values to match the possible states,
combining the two fields in the return value into a single
`Option`.
While most of our closure logic mostly lives in
`locked_close_chan`, some important steps happen in
`convert_channel_err` and `handle_error` (mostly broadcasting a
channel closure `ChannelUpdate` and sending a relevant error
message to our peer).

In a previous commit we removed most instances of
`locked_close_channel` in our closure pipeline, however it was
still called in cases where we did a cooperative close. Here we
remove the remaining direct references to it, always using
`convert_channel_err` instead (now with a new `COOP_CLOSED` macro
variant).
@TheBlueMatt
Copy link
Collaborator Author

Rebased without any further changes.

@TheBlueMatt TheBlueMatt requested review from wpaulino and tnull July 22, 2025 20:07
wpaulino
wpaulino previously approved these changes Jul 22, 2025
The `channel_id` argument to `convert_channel_err` allows us to set
a different channel ID in the error message around the funding
process. However, its not exactly critical to make sure we get it
right, and yet another macro argument is annoying to deal with, so
here we simply drop it and use the `Channel` value.

This means that when force-closing we sometimes send an `error`
with the `temporary_channel_id` rather than the funded
`channel_id`, but its not that critical to get right (and we don't
in all cases anyway), the peer will eventually figure it out when
we reconnect or they try to send more messages about the channel.
Now that we never call `locked_close_channel` directly, the
documentation on it should be updated to note that it shouldn't be
used, rather relying on `convert_channel_err`, which now gets much
of the substantive documentation on closing logic.

Similarly, as `finish_close_channel` is now only called from
`handle_error` we update the docs on both to note the new
semantics.
@TheBlueMatt
Copy link
Collaborator Author

Grrrr, damn cfg flags

$ git diff-tree -U2 f11e79809 0b3ba8519
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 590f57e108..acc549fcb5 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -13004,5 +13004,5 @@ where
 											let mut pending_events = self.pending_events.lock().unwrap();
 											pending_events.push_back((events::Event::ChannelReady {
-												channel_id: *channel_id,
+												channel_id,
 												user_channel_id: funded_channel.context.get_user_id(),
 												counterparty_node_id,

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

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

LGTM

Landing this as the changes since @wpaulino ACKed are minimal

@tnull tnull merged commit 95342dc into lightningdevkit:main Jul 23, 2025
27 of 28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
weekly goal Someone wants to land this this week
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants