[
https://issues.apache.org/jira/browse/RATIS-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shilun Fan updated RATIS-2662:
------------------------------
Description:
{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.
was:
{{RaftReconfigurationBaseTest#testKillLeaderDuringReconf is currently
annotated with @Flaky("RATIS-2251").}}
{{}}
{{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.{}}}{{{}{}}}{{{}{}}}
{{{}{}}}{{{}{}}}
{{ }}{{}}
> Make testKillLeaderDuringReconf deterministic
> ---------------------------------------------
>
> Key: RATIS-2662
> URL: https://issues.apache.org/jira/browse/RATIS-2662
> Project: Ratis
> Issue Type: Bug
> Reporter: Shilun Fan
> Assignee: Shilun Fan
> Priority: Major
>
> {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)
