From: Matt Corallo <git@bluematt.me>
Date: Sun, 9 Apr 2023 01:43:39 +0000 (+0000)
Subject: Remove a race-y debug assertion in new channel update handling
X-Git-Tag: v0.0.115~22^2
X-Git-Url: http://git.bitcoin.ninja/?a=commitdiff_plain;h=29f80269b5c66ffce8afd98a7b3e1205e4b7855d;p=rust-lightning

Remove a race-y debug assertion in new channel update handling

In 6090d9e6a862a2010eb80be56b7449947bc08374 we swapped out old
debug assertions that checked that a lock was `try_lock`able to
test that certain locks weren't held when we needed to be able to
take them in some near branch. However, another slipped in after in
the `ChannelMonitorUpdate` handling rework, which is replaced with
the new debug assertions here.
---

diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 530532a1e..8c8450f6d 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -1588,7 +1588,7 @@ macro_rules! handle_new_monitor_update {
 	($self: ident, $update_res: expr, $update_id: expr, $peer_state_lock: expr, $peer_state: expr, $per_peer_state_lock: expr, $chan: expr, MANUALLY_REMOVING, $remove: expr) => { {
 		// update_maps_on_chan_removal needs to be able to take id_to_peer, so make sure we can in
 		// any case so that it won't deadlock.
-		debug_assert!($self.id_to_peer.try_lock().is_ok());
+		debug_assert_ne!($self.id_to_peer.held_by_thread(), LockHeldState::HeldByThread);
 		match $update_res {
 			ChannelMonitorUpdateStatus::InProgress => {
 				log_debug!($self.logger, "ChannelMonitor update for {} in flight, holding messages until the update completes.",