f use channel monitor update logic from reestablish, not monitor success

Author: TheBlueMatt

lightning/src/ln/channelmanager.rs

@@ -913,23 +913,30 @@ macro_rules! handle_chan_restoration_locked {
 			}
 
 			let funding_broadcastable: Option<Transaction> = $funding_broadcastable; // Force type-checking to resolve
-			macro_rules! handle_cs { () => {
-				if let Some(monitor_update) = chanmon_update {
-					assert!($order == RAACommitmentOrder::RevokeAndACKFirst);
-					// We only ever broadcast a funding transaction in response to a funding_signed
-					// message and the resulting monitor update. Thus, on channel_reestablish
-					// message handling we can't have a funding transaction to broadcast. When
-					// processing a monitor update finishing resulting in a funding broadcast, we
-					// cannot have a second monitor update, thus this case would indicate a bug.
-					assert!(funding_broadcastable.is_none());
-					// Given we were just reconnected or finished updating a channel monitor, the
-					// only case where we can get a new ChannelMonitorUpdate would be if we also
-					// have some commitment updates to send as well.
-					assert!($commitment_update.is_some());
-					if let Err(e) = $self.chain_monitor.update_channel($channel_entry.get().get_funding_txo().unwrap(), monitor_update) {
-						break handle_monitor_err!($self, e, $channel_state, $channel_entry, RAACommitmentOrder::CommitmentFirst, false, true);
+			if let Some(monitor_update) = chanmon_update {
+				// We only ever broadcast a funding transaction in response to a funding_signed
+				// message and the resulting monitor update. Thus, on channel_reestablish
+				// message handling we can't have a funding transaction to broadcast. When
+				// processing a monitor update finishing resulting in a funding broadcast, we
+				// cannot have a second monitor update, thus this case would indicate a bug.
+				assert!(funding_broadcastable.is_none());
+				// Given we were just reconnected or finished updating a channel monitor, the
+				// only case where we can get a new ChannelMonitorUpdate would be if we also
+				// have some commitment updates to send as well.
+				assert!($commitment_update.is_some());
+				if let Err(e) = $self.chain_monitor.update_channel($channel_entry.get().get_funding_txo().unwrap(), monitor_update) {
+					// channel_reestablish doesn't guarantee the order it returns is sensical
+					// for the messages it returns, but if we're setting what messages to
+					// re-transmit on monitor update success, we need to make sure it is sane.
+					let mut order = $order;
+					if $raa.is_none() {
+						order = RAACommitmentOrder::CommitmentFirst;
 					}
+					break handle_monitor_err!($self, e, $channel_state, $channel_entry, order, $raa.is_some(), true);
 				}
+			}
+
+			macro_rules! handle_cs { () => {
 				if let Some(update) = $commitment_update {
 					$channel_state.pending_msg_events.push(events::MessageSendEvent::UpdateHTLCs {
 						node_id: counterparty_node_id,