-
Notifications
You must be signed in to change notification settings - Fork 399
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
Don't disconnect on manual force closes #3088
Don't disconnect on manual force closes #3088
Conversation
lightning/src/ln/channelmanager.rs
Outdated
/// | ||
/// By default, this will send a generic force close error message to the peer if `err_msg` | ||
/// is not specified. If `disconnect_peer` is set to true, the peer will also be disconnected. | ||
pub fn force_close_broadcasting_latest_txn( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh, oops, so #2889 already adds the user-provided error message and should be close to merge, you might want to just rebase on that.
Also, I'm not entirely convinced we want to add the disconnection bool - its not clear to me in what case(s) a user would prefer to disconnect a peer vs just sending an error message and calling it a day.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh, oops, so #2889 already adds the user-provided error message and should be close to merge, you might want to just rebase on that.
Oh nice ok
Also, I'm not entirely convinced we want to add the disconnection bool - its not clear to me in what case(s) a user would prefer to disconnect a peer vs just sending an error message and calling it a day.
SGTM, i can just make it so we don't disconnect by default then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking we'd just make it so we never disconnect :)
97c13b0
to
eb84e4c
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #3088 +/- ##
==========================================
+ Coverage 89.86% 89.88% +0.01%
==========================================
Files 117 117
Lines 97458 97458
Branches 97458 97458
==========================================
+ Hits 87581 87599 +18
+ Misses 7303 7288 -15
+ Partials 2574 2571 -3 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be useful to pass a force-close boolean to force_close_sending_error
, or do we figure the user can just manually disconnect the peer in the next method call?
I'm not clear on any cases where the user would actually care about disconnecting the peer, and they can certainly do so manually if they want. |
Previously we'd always disconnect on force close because the peer had done something bad, but on manual force closes that isn't always the case, e.g. when rejecting a new channel request. This just sends an error message by default instead.