Describe the bug
Two file-source unit tests fail intermittently in the Gradle Build workflow:
FileReaderTest > run_max_read_time_reached_breaks_without_data_loss (observed on build (17))FileReaderPoolTest > addFile_queues_multiple_pending_files (observed on build (11))
Both observed in the same run: https://github.com/opensearch-project/data-prepper/actions/runs/28737597451
Both tests belong to the tail-mode feature added in #6853 and look timing-sensitive (max_read_time, queueing across threads). For context, Gradle Build on main has failed in 8 of its last 10 runs across several modules, so these add to an already noisy signal.
Expected behavior
The tests should pass deterministically, e.g. by replacing wall-clock timing assumptions with awaitility-based polling or injected clocks.
Environment
GitHub Actions ubuntu runners, Java 11/17 matrix.
Describe the bug
Two file-source unit tests fail intermittently in the
Gradle Buildworkflow:FileReaderTest > run_max_read_time_reached_breaks_without_data_loss(observed on build (17))FileReaderPoolTest > addFile_queues_multiple_pending_files(observed on build (11))Both observed in the same run: https://github.com/opensearch-project/data-prepper/actions/runs/28737597451
Both tests belong to the tail-mode feature added in #6853 and look timing-sensitive (
max_read_time, queueing across threads). For context,Gradle Buildon main has failed in 8 of its last 10 runs across several modules, so these add to an already noisy signal.Expected behavior
The tests should pass deterministically, e.g. by replacing wall-clock timing assumptions with awaitility-based polling or injected clocks.
Environment
GitHub Actions ubuntu runners, Java 11/17 matrix.