Summary
ParallelIntegrationTest.testParallelWithMinSuccessful_earlyTermination_consistentResult is flaky - it fails intermittently in CI but succeeds on retry.
Failing build example: https://github.com/aws/aws-durable-execution-sdk-java/actions/runs/26526417904/job/78131146234?pr=408
Root Cause Analysis
The test relies on thread scheduling order to determine which branches complete first when minSuccessful(2) is configured. Branches "a" and "b" are intentionally slowed with Thread.sleep(1000) on the first execution (executionCount ≤ 5), expecting "c", "d", or "e" to finish first and satisfy the min-successful threshold.
However, the test then asserts a deterministic outcome:
assertEquals(ParallelResult.Status.SKIPPED, result.statuses().get(0)); // branch "a"
assertEquals(ParallelResult.Status.SKIPPED, result.statuses().get(1)); // branch "b"
This assumes "a" and "b" are always the ones skipped (i.e., the other branches always win the race). Under thread scheduling pressure in CI (resource contention, CPU throttling), the sleep-based timing is unreliable — a "fast" branch might not complete before a "slow" one wakes up, leading to a different set of 2 successful branches and different skip/success statuses.
Additionally, the replay consistency assertion (assertEquals(initialResult.get(), result)) can fail if the non-deterministic first execution produces a different result ordering than what replay expects.
Suggested Fix
Options:
Use latches instead of sleeps — Use CountDownLatch to explicitly control branch completion order, removing dependence on thread scheduling.
Relax assertions — Instead of asserting specific indices are SKIPPED, assert that exactly 2 branches succeeded and the rest are SKIPPED (in any order).
Increase sleep delta — Make the timing gap larger (e.g., 5s vs instant) to reduce flakiness, though this doesn't fully eliminate the race and slows tests.
Summary
ParallelIntegrationTest.testParallelWithMinSuccessful_earlyTermination_consistentResultis flaky - it fails intermittently in CI but succeeds on retry.Failing build example: https://github.com/aws/aws-durable-execution-sdk-java/actions/runs/26526417904/job/78131146234?pr=408
Root Cause Analysis
The test relies on thread scheduling order to determine which branches complete first when minSuccessful(2) is configured. Branches "a" and "b" are intentionally slowed with Thread.sleep(1000) on the first execution (executionCount ≤ 5), expecting "c", "d", or "e" to finish first and satisfy the min-successful threshold.
However, the test then asserts a deterministic outcome:
This assumes "a" and "b" are always the ones skipped (i.e., the other branches always win the race). Under thread scheduling pressure in CI (resource contention, CPU throttling), the sleep-based timing is unreliable — a "fast" branch might not complete before a "slow" one wakes up, leading to a different set of 2 successful branches and different skip/success statuses.
Additionally, the replay consistency assertion (assertEquals(initialResult.get(), result)) can fail if the non-deterministic first execution produces a different result ordering than what replay expects.
Suggested Fix
Options:
Use latches instead of sleeps — Use CountDownLatch to explicitly control branch completion order, removing dependence on thread scheduling.
Relax assertions — Instead of asserting specific indices are SKIPPED, assert that exactly 2 branches succeeded and the rest are SKIPPED (in any order).
Increase sleep delta — Make the timing gap larger (e.g., 5s vs instant) to reduce flakiness, though this doesn't fully eliminate the race and slows tests.