We've heard about inbound channel requests stalling on the client-side when they fall outside of handshake limits. It seems that when we call accept_inbound_channel and InboundV1Channel::new fails due to the limits, the Close error gets mapped to an APIError instead of being handled.
|
InboundV1Channel::new(&self.fee_estimator, &self.entropy_source, &self.signer_provider, |
|
counterparty_node_id.clone(), &self.channel_type_features(), &peer_state.latest_features, |
|
&unaccepted_channel.open_channel_msg, user_channel_id, &self.default_configuration, best_block_height, |
|
&self.logger, accept_0conf).map_err(|e| { |
|
let err_str = e.to_string(); |
|
log_error!(logger, "{}", err_str); |
|
|
|
APIError::ChannelUnavailable { err: err_str } |
|
}) |
|
} |
We also can't call
ChannelManager::force_close_without_broadcasting_txn after the failure since the channel is removed.
We've heard about inbound channel requests stalling on the client-side when they fall outside of handshake limits. It seems that when we call
accept_inbound_channelandInboundV1Channel::newfails due to the limits, the Close error gets mapped to anAPIErrorinstead of being handled.rust-lightning/lightning/src/ln/channelmanager.rs
Lines 6111 to 6120 in 75822b8
ChannelManager::force_close_without_broadcasting_txnafter the failure since the channel is removed.