Repository: tikv/tikv
File: tests/failpoints/cases/test_split_region.rs (Rust)

Code before:
    //                    ┌───────────┐  ┌───────────┐  ┌───────────┐
    //                    │           │  │           │  │           │
    //      Region 1      │ Peer 1    │  │ Peer 2    │  │ Peer 3    │
    //      [k2, +∞)      │           │  │           │  │           │
    // ───────────────────┼───────────┼──┼───────────┼──┼───────────┼──
    //                    │           │  │           │  │           │
    //      Region 1000   │ Peer 1001 │  │ Peer 1003 │  │ Peer 1002 │
    //      (-∞, k2)      │           │  │           │  │           │
    //                    └───────────┘  └───────────┘  └───────────┘
    //                       Store 1        Store 2        Store 3
    //
    // In this test, there is a split operation and Peer 1003 will be created
    // twice (by raft message and by split). The new Peer 1003 will replace the
    // old Peer 1003 and but it will be immediately removed. This test verifies
    // that TiKV would not panic if the old Peer 1003 continues to process a
    // snapshot message.

    let mut cluster = new_node_cluster(0, 3);
    configure_for_merge(&mut cluster.cfg);
    cluster.cfg.raft_store.right_derive_when_split = true;
    cluster.cfg.raft_store.store_batch_system.max_batch_size = Some(1);
    cluster.cfg.raft_store.store_batch_system.pool_size = 2;
    cluster.cfg.raft_store.apply_batch_system.max_batch_size = Some(1);
    cluster.cfg.raft_store.apply_batch_system.pool_size = 2;
    let pd_client = Arc::clone(&cluster.pd_client);
    pd_client.disable_default_operator();

    fail::cfg("on_raft_gc_log_tick", "return()").unwrap();
    let r1 = cluster.run_conf_change();
    // Add Peer 3
    pd_client.must_add_peer(r1, new_peer(3, 3));
    assert_eq!(r1, 1);

    // Pause the snapshot apply of Peer 2.
    let before_check_snapshot_1_2_fp = "before_check_snapshot_1_2";
    fail::cfg(before_check_snapshot_1_2_fp, "pause").unwrap();

    // Add Peer 2. The peer will be created but stuck at applying snapshot due
    // to the failpoint above.
    pd_client.must_add_peer(r1, new_peer(2, 2));
    cluster.must_put(b"k1", b"v1");

    // Before the split, pause the snapshot apply of Peer 1003.
    let before_check_snapshot_1000_2_fp = "before_check_snapshot_1000_2";
    fail::cfg(before_check_snapshot_1000_2_fp, "pause").unwrap();

    // Split the region into Region 1 and Region 1000. Peer 1003 will be created
    // for the first time when it receives a raft message from Peer 1001, but it
    // will remain uninitialized, waiting for a raft snapshot.
    let region = pd_client.get_region(b"k1").unwrap();
    cluster.must_split(&region, b"k2");

Review comment (suggestion):
```suggestion
    //      Region 1000   │ Peer 1001 │  │ Peer 1002 │  │ Peer 1003 │
```

I think 1003 is in store3？

Code after:

#[test]
fn test_stale_peer_handle_vote() {
    test_stale_peer_handle_raft_msg("on_vote_msg_1000_2");
}

#[test]
fn test_stale_peer_handle_append() {
    test_stale_peer_handle_raft_msg("on_append_msg_1000_2");
}

#[test]
fn test_stale_peer_handle_heartbeat() {
    test_stale_peer_handle_raft_msg("on_heartbeat_msg_1000_2");
}

fn test_stale_peer_handle_raft_msg(on_handle_raft_msg_1000_2_fp: &str) {
    // The following diagram represents the final state of the test:
    //
    //                    ┌───────────┐  ┌───────────┐  ┌───────────┐
    //                    │           │  │           │  │           │
    //      Region 1      │ Peer 1    │  │ Peer 2    │  │ Peer 3    │
    //      [k2, +∞)      │           │  │           │  │           │
    // ───────────────────┼───────────┼──┼───────────┼──┼───────────┼──
    //                    │           │  │           │  │           │
    //      Region 1000   │ Peer 1001 │  │ Peer 1003 │  │ Peer 1002 │
    //      (-∞, k2)      │           │  │           │  │           │
    //                    └───────────┘  └───────────┘  └───────────┘
    //                       Store 1        Store 2        Store 3
    //
    // In this test, there is a split operation and Peer 1003 will be created
    // twice (by raft message and by split). The new Peer 1003 will replace the
    // old Peer 1003 and but it will be immediately removed. This test verifies
    // that TiKV would not panic if the old Peer 1003 continues to process a
    // remaining raft message (which may be a snapshot/vote/heartbeat/append
    // message).

    let mut cluster = new_node_cluster(0, 3);
    configure_for_merge(&mut cluster.cfg);
    cluster.cfg.raft_store.right_derive_when_split = true;
    cluster.cfg.raft_store.store_batch_system.max_batch_size = Some(1);
    cluster.cfg.raft_store.store_batch_system.pool_size = 2;
    cluster.cfg.raft_store.apply_batch_system.max_batch_size = Some(1);
    cluster.cfg.raft_store.apply_batch_system.pool_size = 2;
    let pd_client = Arc::clone(&cluster.pd_client);
    pd_client.disable_default_operator();

    fail::cfg("on_raft_gc_log_tick", "return()").unwrap();
    let r1 = cluster.run_conf_change();
    // Add Peer 3
    pd_client.must_add_peer(r1, new_peer(3, 3));