Additional closing cleanups post-#3881 #3899
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
👋 Thanks for assigning @tnull as a reviewer! |
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
`ChannelManager::force_close_channel_with_peer` takes the peer's node_id as a parameter and then returns it, presumably leftover from before we stored channels indexed by peers. Here we simply drop the return value.
When a channel is "coop" closed prior to it being funded, it is closed immediately. Instead of reporting `ClosureReason::*InitiatedCooperativeClosure` (which would be somewhat misleading), we report `ClosureReason::CounterpartyCoopClosedUnfundedCHannel` when our counterparty does it. However, when we do it, we report `ClosureReason::HolderForceClosed`, which is highly confusing given the user did *not* call a force-closure method. Instead, here, we add a `ClosureReason::LocallyCoopClosedUnfundedChannel` to match the `CounterpartyCoopClosedUnfundedCHannel` variant and use it.
`ClosureReason::HolderForceClosed` says explicitly in its docs "Closure generated from `ChannelManager...`, called by the user." However, we were using it extensively when we fail a channel due to errors handling messages or generating our own responses. Here, we convert these cases to the catch-all `ClosureReason::ProcessingError` which exists to communicate errors including a string that describes what happened. This should substantially improve debug-ability in closure cases by avoiding having to pull up logs.
Here we fix a few cases of swallowing appropriate `ClosureReason`s and expand `ClosureReason::FundingTimedOut` to include when we didn't get a channel funded in time, rather than using `HolderForceClosed`.
In d17e759 we added the ability for users to decide which message to send to peers when we force-close a channel. Here we pipe that message back out through the channel closure event via a new `message` field in `ClosureReason::HolderForceClosed`. This is nice to have but more importantly will be used in a coming commit to simplify the internal interface to the force-closure logic.
Removes totally unnecessary `#[inline]`s on `MsgHandleErrInternal` methods (LLVM will decide for us if it makes sense to inline something, explicit `#[inline(always)]` belongs only on incredibly performance-sensitive code and `#[inline]` belongs only on short public methods that should be inlined into downstream crates) and `rustfmt` `MsgHandleErrInternal::from_chan_no_close`.
`ChannelManager` has two public methods to force-close a (single) channel - `force_close_broadcasting_latest_txn` and `force_close_without_broadcasting_txn`. The second exists to allow a user who has restored a stale backup to (sort of) recover their funds by starting, force-closing channels without broadcasting their latest state, and only then reconnecting to peers (which would otherwise cause a panic due to the stale state). To my knowledge, no one has ever implemented this (fairly half-assed) recovery flow, and more importantly its rather substantially broken. `ChannelMonitor` has never tracked any concept of whether a channel is stale, and if we connect blocks towards an HTLC time-out it will immediately broadcast the stale state anyway. Finally, we really shouldn't encourage users to try to "recover" from a stale state by running an otherwise-operational node on the other end. Rather, we should formalize such a recovery flow by having a `ChainMonitor` variant that takes a list of `ChannelMonitor`s and claims available funds, dropping the `ChannelManager` entirely. While work continues towards that goal, having long-broken functionality in `ChannelManager` is also not acceptable, so here we simply remove the "without broadcasting" force-closure version. Fixes lightningdevkit#2875
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). While its fine to use `locked_close_chan` directly when we manually write out the relevant extra steps, its nice to avoid it to DRY up some of our closure logic, which we do here.
`Channel`'s new `FundingScope` exists to store both the channel's live funding information as well as any in-flight splices. In order to keep the patches which introduced and began using it simple, it was exposed outside of `channel.rs` to `channelmanager.rs`, breaking the `Channel` abstraction somewhat. Here we remove one case of `FundingScope` being passed around `channelmanager.rs` (in the hopes of eventually keeping it entirely contained within `channel.rs`). Specifically, we remove the `FundingScope` parameter from `locked_close_channel`.
In a previous commit, we removed the ability for users to pick whether we will broadcast a commitment transaction on channel closure. However, that doesn't mean that there is no value in never broadcasting commitment transactions on channel closure. Rather, we use it to avoid broadcasting transactions which we know cannot confirm if the channel's funding transaction was not broadcasted. Here we make this relationship more formal by splitting the force-closure handling logic in `Channel` into the existing `ChannelContext::force_shutdown` as well as a new `ChannelContext::abandon_unfunded_chan`. `ChannelContext::force_shutdown` is the only public method, but it delegates to `abandon_unfunded_chan` based on the channel's state. This has the nice side effect of avoiding commitment transaction broadcasting when a batch open fails to get past the funding stage.
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).
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.
TheBlueMatt
force-pushed
the
2025-06-close-cleanup
branch
from
0dac107 to
77fabef
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3899 +/- ##
==========================================
+ Coverage 88.86% 88.91% +0.04%
==========================================
Files 165 165
Lines 118886 118900 +14
Branches 118886 118900 +14
==========================================
+ Hits 105650 105717 +67
+ Misses 10911 10864 -47
+ Partials 2325 2319 -6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
tnull
reviewed
Jun 30, 2025
|
Yea, realized that but will probably fix after #3881 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.