Raise APIError from close_channel #196
Conversation
src/ln/channel.rs
Outdated
| } | ||
| assert_eq!(self.channel_state & ChannelState::ShutdownComplete as u32, 0); | ||
| if self.channel_state & (ChannelState::PeerDisconnected as u32) == ChannelState::PeerDisconnected as u32 { | ||
| return Err(HandleError{err: "Cannot begin shutdown while peer is disconnected, maybe force-close instead?", action: None}); | ||
| return Err(APIError::APIMisuseError{err: "Cannot begin shutdown while peer is disconnected, maybe force-close instead?"}); |
There was a problem hiding this comment.
Hmm, can we really call this "Misuse"? Maybe some less-user-blaming enum entry in APIError?
There was a problem hiding this comment.
added ChannelUnavailalbe enum entry for APIError.
| for htlc in self.pending_outbound_htlcs.iter() { | ||
| if htlc.state == OutboundHTLCState::LocalAnnounced { | ||
| return Err(HandleError{err: "Cannot begin shutdown with pending HTLCs, call send_commitment first", action: None}); | ||
| return Err(APIError::APIMisuseError{err: "Cannot begin shutdown with pending HTLCs. Process pending events first"}); |
There was a problem hiding this comment.
I think we can debug_assert!(false) here.
There was a problem hiding this comment.
but the client can call close_channel() anytime?
There was a problem hiding this comment.
Oh, oops, confused myself as to what LocalAnnounced meant. Forgot that it implied "included in sent commitment_signed". Indeed, I was mistaken.
yuntai
force-pushed
the
shutdown-apify
branch
from
6a63d4d to
d0e8d26
Compare
src/ln/channelmanager.rs
Outdated
| @@ -439,7 +439,7 @@ impl ChannelManager { | |||
| (res, chan_entry.get().get_their_node_id(), Some(chan_entry.remove_entry().1)) | |||
| } else { (res, chan_entry.get().get_their_node_id(), None) } | |||
| }, | |||
| hash_map::Entry::Vacant(_) => return Err(HandleError{err: "No such channel", action: None}) | |||
| hash_map::Entry::Vacant(_) => return Err(APIError::APIMisuseError{err: "No such channel"}) | |||
There was a problem hiding this comment.
Shouldnt this also be ChannelUnavailable (after all, there are always going to be races on the client's side where a channel gets (force-)closed between when they decide to close it and when they call close_channel).
yuntai
changed the title
No description provided.