[
https://issues.apache.org/jira/browse/RATIS-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsz-wo Sze resolved RATIS-2662.
-------------------------------
Fix Version/s: 3.4.0
Resolution: Fixed
The pull request is now merged. Thanks, [~slfan1989] !
> Make testKillLeaderDuringReconf deterministic
> ---------------------------------------------
>
> Key: RATIS-2662
> URL: https://issues.apache.org/jira/browse/RATIS-2662
> Project: Ratis
> Issue Type: Test
> Components: test
> Reporter: Shilun Fan
> Assignee: Shilun Fan
> Priority: Major
> Fix For: 3.4.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> {code:java}
> RaftReconfigurationBaseTest#testKillLeaderDuringReconf is currently
> annotated with @Flaky("RATIS-2251"). {code}
>
> {{The test creates a new peer by calling addNewPeers(1, false).}}
>
> The new server is initially created with an empty Raft configuration and is
> expected to start in the initializing state.
>
> However, the test later starts the new peer by calling restartServer(peerId,
> false). restartServer removes the previously
> created server and recreates it using the current cluster.group, which
> already contains the new peer in the target configuration.
>
> As a result, the new peer starts as a regular voting follower instead of an
> initializing peer. If its first election timeout occurs before AppendEntries
> arrives from the leader, the new peer starts a PRE_VOTE election. Since the
> leader's committed configuration does not contain the new peer yet, the
> leader may return shouldShutdown=true, causing
> the new peer to enter CLOSED.
>
> The original test also ignores TimeoutException from the asynchronous
> setConfiguration request and skips the final configuration check when the new
> peer is CLOSED. Therefore, an incomplete reconfiguration may either make the
> test flaky or be incorrectly treated as successful.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
