You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In upcoming commits, we'll move to creating multi-hop blinded paths during the
process of creating a revoke_and_ack message within the Channel struct. These
paths will be included in said RAA to be used as reply paths for often-offline
senders held_htlc_available messages.
Because we hold the per-peer lock corresponding to the Channel while creating
this RAA, we can't use our typical approach of calling
ChannelManager::get_peers_for_blinded_path to create these blinded paths.
The ::get_peers method takes each peer's lock in turn in order to check for
usable channels/onion message feature support, and it's not permitted to hold
multiple peer state locks at the same time due to the potential for deadlocks
(see the debug_sync module).
To avoid taking other peer state locks while holding a particular Channel's
peer state lock, here we cache the set of peers in the OffersMessageFlow, which
is the struct that ultimately creates the blinded paths for the RAA.
"Got a channel_ready message for an unfunded channel!".into())), chan_entry)
10434
10435
}
10435
10436
},
10436
10437
hash_map::Entry::Vacant(_) => {
10437
-
Err(MsgHandleErrInternal::send_err_msg_no_close(format!("Got a message for a channel from the wrong node! No such channel for the passed counterparty_node_id {}", counterparty_node_id), msg.channel_id))
10438
+
return Err(MsgHandleErrInternal::send_err_msg_no_close(format!("Got a message for a channel from the wrong node! No such channel for the passed counterparty_node_id {}", counterparty_node_id), msg.channel_id))
0 commit comments