Move a ton of Channel functions to ChannelError from HandleError #254
Conversation
| $self.force_close_channel(&msg.channel_id); | ||
| } | ||
| }, | ||
| &Some(msgs::ErrorAction::DisconnectPeer { msg: None }) => {}, |
There was a problem hiding this comment.
Even if it's just a move and was already like that, but why we don't peer_disconnected here too ?
There was a problem hiding this comment.
If we're just disconnecting them but not sending an error message we shouldn't be closing the channel. In the future you might imagine disconnecting a peer without closing the channels associated with that peer to try to recover from some state inconsistency.
|
utACK, good luck for coming refactors. |
|
Rebased. Indeed, I'm in no rush for per-channel locks, if someone feels like doing it, great, but its gonna conflict a bunch so maybe let some bigger stuff land first anyway. |
TheBlueMatt
force-pushed
the
2018-11-channelerror
branch
from
b2549f4 to
12cc596
Compare
This is a big patch, but its all very mechanical, everything here should be pretty obvious, and it all has to happen at once due to a few common utility functions all having the same return type. Note that this exposes a race in channel closure where we may access a channel via some non-peer-specific mechanism like forwarding an HTLC or sending a payment during the time between the channel gave us a Close error and expected us to never call it again and the time we actually removed it from the channel_state set outside of the internal_* handler.
TheBlueMatt
force-pushed
the
2018-11-channelerror
branch
from
12cc596 to
90816dd
Compare
|
Rebased after #231 with two extra tiny fixes in tests. Will merge once travis passes. |
This is a big patch, but its all very mechanical, everything here
should be pretty obvious, and it all has to happen at once due to a
few common utility functions all having the same return type.
Note that this exposes a race in channel closure where we may
access a channel via some non-peer-specific mechanism like
forwarding an HTLC or sending a payment during the time between
the channel gave us a Close error and expected us to never call it
again and the time we actually removed it from the channel_state
set outside of the internal_* handler.
Refactor of channelmanager message handlers for that incoming....