Clean Up Funding Error Handling and shutdown #2809
Merged
Conversation
This file contains 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
If we promote our channel to `AwaitingChannelReady` after adding funding info, but still have `MONITOR_UPDATE_IN_PROGRESS` set, we haven't broadcasted the funding transaction yet and thus should return values from `unbroadcasted_funding[_txid]` and generate a `DiscardFunding` event.
Currently the channel shutdown sequence has a number of steps which all the shutdown callsites have to call. Because many shutdown cases are rare error cases, its relatively easy to miss a call and leave users without `Event`s or miss some important cleanup. One of those steps, calling `issue_channel_close_events`, is rather easy to remove, as it only generates two events, which can simply be moved to another shutdown step. Here we move the first of the two events, `DiscardFunding`, into `finish_force_close_channel`.
Currently the channel shutdown sequence has a number of steps which all the shutdown callsites have to call. Because many shutdown cases are rare error cases, its relatively easy to miss a call and leave users without `Event`s or miss some important cleanup. One of those steps, calling `issue_channel_close_events`, is rather easy to remove, as it only generates two events, which can simply be moved to another shutdown step. Here we remove `issue_channel_close_events` by moving `ChannelClosed` event generation into `finish_force_close_channel`.
We'd previously assumed that LDK would receive `funding_transaction_generated` prior to our peer learning the txid and panicked if the peer tried to open a redundant channel to us with the same funding outpoint. While this assumption is generally safe, some users may have out-of-band protocols where they notify their LSP about a funding outpoint first, or this may be violated in the future with collaborative transaction construction protocols, i.e. the upcoming dual-funding protocol.
In e06484b, we added specific handling for outbound-channel initial monitor updates failing - in such a case we have a counterparty who tried to open a second channel with the same funding info we just gave them, causing us to force-close our outbound channel as it shows up as duplicate-funding. Its largely harmless as it leads to a spurious force-closure of a channel with a peer doing something absurd, however it causes the `full_stack_target` fuzzer to fail. Sadly, in 574c77e, as we were dropping handling of `PermanentFailure` handling for updates, we accidentally dropped handling for initial updates as well. Here we fix the issue (again) and add a test.
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2809 +/- ##
==========================================
+ Coverage 88.46% 88.79% +0.33%
==========================================
Files 114 114
Lines 91806 95767 +3961
Branches 91806 95767 +3961
==========================================
+ Hits 81214 85038 +3824
- Misses 8112 8289 +177
+ Partials 2480 2440 -40 ☔ View full report in Codecov by Sentry. |
wpaulino
approved these changes
Jan 4, 2024
dunxen
approved these changes
Jan 10, 2024
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.
When updating the
full_stack_targetfuzzer as a part of #2808, I found a number of ways that funding errors aren't entirely properly handled (ie missing events in edge cases) and one case of a potential panic in extremely rare deployments (which, sadly, we're fixing for a second time, cause the first time we couldn't figure out how to write a test and concluded it was unreachable, but then later regressed and the fuzzer found it again).