Xline
Xline copied to clipboard
[Bug]: wrong response of `fast_round` if there are two leaders
Description about the bug
In #582, the test case will failed, we should fixed it.
/// FIXME: two leader
/// TODO: fix in subsequence PR
#[traced_test]
#[tokio::test]
#[should_panic]
async fn test_unary_fast_round_with_two_leader() {
let connects = init_mocked_connects(5, |id, conn| {
conn.expect_propose().return_once(move |_req, _timeout| {
let resp = match id {
// The execution result has been returned, indicating that server(0) has also recorded the command.
0 => ProposeResponse::new_result::<TestCommand>(&Ok(TestCommandResult::new(
vec![1],
vec![1],
))),
// imagine that server(1) is the new leader
1 => ProposeResponse::new_result::<TestCommand>(&Ok(TestCommandResult::new(
vec![2],
vec![2],
))),
2 | 3 => ProposeResponse::new_empty(),
4 => return Err(CurpError::key_conflict()),
_ => unreachable!("there are only 3 nodes"),
};
Ok(tonic::Response::new(resp))
});
});
// old local leader(0), term 1
let unary = Unary::<TestCommand>::new(connects, None, Some((0, 1)));
let res = unary
.fast_round(ProposeId(0, 0), &TestCommand::default())
.await
.unwrap()
.unwrap();
// quorum: server(0, 1, 2, 3)
assert_eq!(res, TestCommandResult::new(vec![2], vec![2]));
}
Version
0.6.0 (Default)
Relevant log output
No response
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
By introducing leader_id
and term
in ProposeRequest
, we may fix that bug.