Siyao Meng created HDDS-15822:
---------------------------------
Summary: Fix flaky TestStorageVolumeChecker#testNumScansSkipped
Key: HDDS-15822
URL: https://issues.apache.org/jira/browse/HDDS-15822
Project: Apache Ozone
Issue Type: Bug
Components: test
Reporter: Siyao Meng
Assignee: Siyao Meng
Generated-by: Claude Code (Opus 4.8)
{{TestStorageVolumeChecker#testNumScansSkipped}} fails intermittently with
{{expected: <1> but was: <2>}} (seen in upstream CI on 2026-07-09).
The test uses the real {{ThrottledAsyncChecker}}, which runs volume checks on a
background executor and wraps them with {{Futures.withTimeout}}. The callback
that records each check's {{completedAt}} runs on those executor threads. On a
busy JVM this races with the test's {{timer.advance()}}, so a check's
{{completedAt}} is occasionally recorded against a later timer value. On the
third {{checkAllVolumes}} call the affected volume then looks like it is still
within {{minMsBetweenChecks}} and is skipped, which inflates
{{numScansSkipped}} from 1 to 2.
Fix: make the check synchronous for this test by installing a
{{ThrottledAsyncChecker}} backed by a direct executor service, and set
{{diskCheckTimeout}} to zero so no {{Futures.withTimeout}} wrapper is created.
{{completedChecks}} is then fully populated before {{checkAllVolumes}} returns,
which removes the race. The throttling gap ({{getDiskCheckMinGap}}) is
unchanged, so the test still verifies skip counting, and the asynchronous per
volume timeout path stays covered by the dedicated test added in HDDS-14871.
The change is limited to the test.
Testing: ran {{testNumScansSkipped}} 100 times locally with 0 failures. Ran the
full {{TestStorageVolumeChecker}} class (20 tests) multiple times with no
failures. Checkstyle clean.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
