You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ratis.apache.org by "Tsz-wo Sze (Jira)" <ji...@apache.org> on 2026/05/31 15:42:00 UTC

[jira] [Resolved] (RATIS-2548) Stabilize timing-sensitive Ratis tests by replacing fixed sleeps and racy assertions

     [ https://issues.apache.org/jira/browse/RATIS-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tsz-wo Sze resolved RATIS-2548.
-------------------------------
    Fix Version/s: 3.3.0
         Assignee: Yongzao Dan
       Resolution: Fixed

The pull request is now merged.  Thanks, [~yongzao]!

> Stabilize timing-sensitive Ratis tests by replacing fixed sleeps and racy assertions
> ------------------------------------------------------------------------------------
>
>                 Key: RATIS-2548
>                 URL: https://issues.apache.org/jira/browse/RATIS-2548
>             Project: Ratis
>          Issue Type: Test
>          Components: test
>            Reporter: Yongzao Dan
>            Assignee: Yongzao Dan
>            Priority: Major
>             Fix For: 3.3.0
>
>          Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Several tests rely on fixed sleeps or immediate assertions while asynchronous Raft work is still in progress. These assumptions can fail on slower CI machines, especially when restart threads, log cleanup, state machine application, or leadership transitions complete later than expected.
> Observed flaky patterns:
> - `LinearizableReadTests` assumes a fixed sleep is enough for the delayed write to be committed before issuing follower reads.
> - `TestLinearizableReadRepliedIndexWithGrpc` sleeps while waiting for the leader state machine to apply writes under a blocked `ReplyFlusher`.
> - `RaftBasicTests` can proceed to log checks before leader/follower restart futures have completed if an earlier assertion fails.
> - `RaftLogTruncateTests` asserts an empty transaction context map immediately even though cleanup may complete asynchronously.
> - `ElectionCommandIntegrationTest` assumes a step-down immediately makes all servers followers, which is racy with the next election.
> Proposed fix:
> - Replace fixed sleeps with `JavaUtils.attempt` / `attemptRepeatedly` checks for the concrete condition each test needs.
> - In `RaftBasicTests`, wait for restart futures in a `finally` block before continuing to log assertions.
> - In `RaftLogTruncateTests`, wait for the transaction context map to become empty.
> - In `ElectionCommandIntegrationTest`, pause the current leader before step-down and wait until a different leader is elected.
> - In replied-index linearizable read tests, wait for the state machine count instead of assuming a fixed delay.
> Test plan:
> - Run the affected tests repeatedly:
> -`LinearizableReadTests` implementations, especially gRPC replied-index variants.
> -`RaftBasicTests`.
> -`RaftLogTruncateTests`.
> -`ElectionCommandIntegrationTest`.
> - Run the relevant CI buckets after the PR update.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)