Verify channel-monitor processes blocks with skipped best_block

Author: G8XSU

lightning/src/ln/functional_tests.rs

@@ -4080,6 +4080,37 @@ fn test_channel_ready_without_best_block_updated() {
 	nodes[1].node.handle_channel_ready(&nodes[0].node.get_our_node_id(), &as_channel_ready);
 }
 
+#[test]
+fn test_channel_monitor_skipping_current_best_block() {
+	let chanmon_cfgs = create_chanmon_cfgs(2);
+	let node_cfgs = create_node_cfgs(2, &chanmon_cfgs);
+	let node_chanmgrs = create_node_chanmgrs(2, &node_cfgs, &[None, None]);
+	let mut nodes = create_network(2, &node_cfgs, &node_chanmgrs);
+
+	// Let ChannelManager get ahead of chainmonitor by 1 block.
+	// This is to emulate race-condition where newly added channel-monitor skips processing 1 block.
+	let height_1 = nodes[0].best_block_info().1 + 1;
+	let mut block_1 = create_dummy_block(nodes[0].best_block_hash(), height_1, Vec::new());
+
+	nodes[0].blocks.lock().unwrap().push((block_1.clone(), height_1));
+	nodes[0].node.block_connected(&block_1, height_1);
+
+	// Create channel, and it gets added to chainmonitor in funding_created.
+	let funding_tx = create_chan_between_nodes_with_value_init(&nodes[0], &nodes[1], 1_000_000, 0);
+
+	// Now channel-monitor in chain-monitor doesn't know about block_1, but it's best_block is block_1,
+	// since that was populated by channel-manager.
+	// Later on, subsequent blocks are connected to both channel_manager and chainmonitor.
+	// Hence, channel-monitor skipped block_1, directly tries to process_chain_data with subsequent blocks.
+	*nodes[0].connect_style.borrow_mut() = ConnectStyle::BestBlockFirst;
+	confirm_transaction_at(&nodes[0], &funding_tx, nodes[0].best_block_info().1 + 1);
+	connect_blocks(&nodes[0], CHAN_CONFIRM_DEPTH);
+
+	// Ensure nodes[0] generates a channel_ready after the transactions_confirmed
+	let as_channel_ready = get_event_msg!(nodes[0], MessageSendEvent::SendChannelReady, nodes[1].node.get_our_node_id());
+	nodes[1].node.handle_channel_ready(&nodes[0].node.get_our_node_id(), &as_channel_ready);
+}
+
 #[test]
 fn test_drop_messages_peer_disconnect_dual_htlc() {
 	// Test that we can handle reconnecting when both sides of a channel have pending