Follow ups to "Remove convert channel err macro" #4281
Conversation
This commit is a pure move.
This method isn't converting an error.
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4281 +/- ##
==========================================
+ Coverage 89.37% 89.39% +0.02%
==========================================
Files 180 180
Lines 139847 139846 -1
Branches 139847 139846 -1
==========================================
+ Hits 124983 125012 +29
+ Misses 12269 12253 -16
+ Partials 2595 2581 -14
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| /// [`ChannelManager::finish_close_channel`]. | ||
| /// | ||
| /// Returns a mapped error. | ||
| fn get_coop_close_err( |
There was a problem hiding this comment.
Hmmmmm, its not really just a "getter", though. Even convert was maybe a bit of a misnomer, but its really doing a bunch of stuff - its doing the initial channel closure handling, at least the locked part. Maybe locked_handle_coop_close (and similarly rename the rest locked_handle_*_close)?
| /// When a channel is removed, two things need to happen: | ||
| /// (a) [`ChannelManager::convert_channel_err`] must be called in the same `per_peer_state` lock as the | ||
| /// channel-closing action, | ||
| /// (a) The close error must be converted to [`MsgHandleErrInternal`] in the same `per_peer_state` lock as the |
There was a problem hiding this comment.
Depending on if we rename the other methods from convert this might also be confusing. But this also implies that you can just build the MsgHandleErrInternal rather than calling one of the 3 close-handle-convert methods, maybe just link all of them?
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
3 participants
Follows up to #4275