Skip to content

[0.0.123] Don't attempt to resume channels if we already exchanged funding #3034

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

Conversation

TheBlueMatt
Copy link
Collaborator

ddf75af introduced the ability to re-exchange our ChannelOpen after a peer disconnects if we didn't complete funding on our end. It did not implement nor consider what would happen if we re-connected after we created our own funding transactions, and currently it panics (and even if it did not it would replay the FundingTransactionGenerated event to users).

This addresses this in a temporary fashion to fix the immediate panic for 0.0.123, allowing us to fix the issue more fully later.

Note that this branch is not targeting upstream but rather the 0.0.123 branch.

/// Returns true if we can resume the channel by sending the [`msgs::OpenChannel`] again.
pub fn is_resumable(&self) -> bool {
!self.context.have_received_message() &&
self.context.cur_holder_commitment_transaction_number == INITIAL_COMMITMENT_NUMBER
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this method necessary? It seems like have_received_message() should cover it, I don't see how we could be beyond the initial commitment number if we've only just sent our init 🤔 I'm ok with it because it makes the callsite more readable, though.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yea, I think they're redundant, I just figured we should do the thing that matches the two panics below exactly rather than trying to avoid the extra check. I also like having the callsites be more readable so went with a new method :).

ddf75af introduced the ability to re-exchange our `ChannelOpen`
after a peer disconnects if we didn't complete funding on our end.
It did not implement nor consider what would happen if we
re-connected after we created our own funding transactions, and
currently it panics (and even if it did not it would replay the
`FundingTransactionGenerated` event to users).

This addresses this in a temporary fashion to fix the immediate
panic for 0.0.123, allowing us to fix the issue more fully later.
@TheBlueMatt TheBlueMatt force-pushed the 2024-04-2982-123-fix branch from 4c1019f to 21ab2dc Compare May 1, 2024 21:26
@codecov-commenter
Copy link

codecov-commenter commented May 1, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.44%. Comparing base (d25d55a) to head (21ab2dc).
Report is 22 commits behind head on 0.0.123.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@             Coverage Diff             @@
##           0.0.123    #3034      +/-   ##
===========================================
+ Coverage    89.15%   89.44%   +0.29%     
===========================================
  Files          118      118              
  Lines        97521    99738    +2217     
  Branches     97521    99738    +2217     
===========================================
+ Hits         86941    89211    +2270     
+ Misses        8343     8272      -71     
- Partials      2237     2255      +18     

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

@TheBlueMatt
Copy link
Collaborator Author

Squash-pushed comment fix:

$ git diff-tree -U2 4c1019fd 21ab2dc2
diff --git a/lightning/src/ln/functional_tests.rs b/lightning/src/ln/functional_tests.rs
index 43abe62d3..e45e4320a 100644
--- a/lightning/src/ln/functional_tests.rs
+++ b/lightning/src/ln/functional_tests.rs
@@ -3767,7 +3767,7 @@ fn test_peer_disconnected_before_funding_broadcasted() {
 	}

-	// Ensure that the channel is closed with `ClosureReason::HolderForceClosed`
-	// when the peers are disconnected and do not reconnect before the funding
-	// transaction is broadcasted.
+	// Ensure that the channel is closed with `ClosureReason::DisconnectedPeer` and a
+	// `DiscardFunding` event when the peers are disconnected and do not reconnect before the
+	// funding transaction is broadcasted.
 	check_closed_event!(&nodes[0], 2, ClosureReason::DisconnectedPeer, true
 		, [nodes[1].node.get_our_node_id()], 1000000);

Copy link
Member

@shaavan shaavan left a comment

Choose a reason for hiding this comment

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

Looks like a reasonable fix until we can get the #2983 working!
Hopefully, I will get that running properly very soon!

@valentinewallace
Copy link
Contributor

Just checked and CI failures look unrelated. Gonna land this since it's a trivial patch, looks good to @shaavan, and the test coverage repros the bug on main as expected.

@valentinewallace valentinewallace merged commit f0a3029 into lightningdevkit:0.0.123 May 2, 2024
13 of 16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants