From bdb423b51b8be534b7c17d45bcdd52e4821043e2 Mon Sep 17 00:00:00 2001 From: Shizuo Fujita Date: Thu, 9 Jul 2026 12:42:18 +0900 Subject: [PATCH] test_in_tail: fix flaky throttling test by widening the lower time bound (#5418) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit **Which issue(s) this PR fixes**: Fixes # **What this PR does / why we need it**: The `test "lines collected with throttling"` still fails intermittently even after #5381, especially on CI runners: ``` 4) Failure: test: lines collected with throttling(TailInputTest::throttling logs at in_tail level): elapsed_seconds 1.8289766999998847 is out of allowed range: lower: 1.88 [sec] upper: 3.3200000000000003 [sec]. ``` The throttling only guarantees that consecutive *read starts* (`start_reading_time`) are at least `rate_period` apart: ``` S_{N+1} - S_N >= rate_period # always holds ``` However, the test measures the interval between *emit* events. An emit happens after a whole batch (`limit` lines, ~8MB here) has been read, i.e. at `read_start + read_duration`: ``` emit_N ~= S_N + Tread_N measured gap = (S_{N+1} - S_N) + (Tread_{N+1} - Tread_N) ~= rate_period + (Tread_{N+1} - Tread_N) ``` So when an earlier batch is read more slowly than the next one — which is common for the first batch right after the file is opened — the measured emit interval dips below `rate_period`. The observing thread's 0.1s polling jitter adds to this. The reported failures (~0.17s below 2.0s) are fully explained by this read-time skew plus polling jitter. The previous lower bound only accounted for the polling interval (`sleep_interval * safety_ratio = 0.12`), which was too tight and asymmetric with the upper bound (which already includes the watcher tick). This PR uses a symmetric jitter that also tolerates the read/observation latency, so the allowed range becomes `[0.68, 3.32]` sec. This is a test-only measurement issue, not a product bug. The strict per-cycle line-count assertion (`assert_equal(limit, d.record_count - prev_count)`) is kept intact, so a regression that actually breaks throttling (emits back to back, gap ~0s) is still detected. **Docs Changes**: N/A **Release Note**: N/A Signed-off-by: Shizuo Fujita Signed-off-by: github-actions[bot] --- test/plugin/test_in_tail.rb | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/test/plugin/test_in_tail.rb b/test/plugin/test_in_tail.rb index a2d11b9f1c..e00ca777b9 100644 --- a/test/plugin/test_in_tail.rb +++ b/test/plugin/test_in_tail.rb @@ -2769,10 +2769,18 @@ def test_lines_collected_with_no_throttling(data) sleep_interval = 0.1 tail_watcher_interval = 1.0 # hard coded value in in_tail safety_ratio = 1.2 - lower_jitter = sleep_interval * safety_ratio - upper_jitter = (tail_watcher_interval + sleep_interval) * safety_ratio - lower_interval = rate_period - lower_jitter - upper_interval = rate_period + upper_jitter + # The throttling guarantees that consecutive *read starts* are at least + # rate_period apart. However, this test measures the interval between + # *emit* events, and an emit happens after a whole batch (= `limit` lines, + # ~8MB here) has been read, i.e. at `read_start + read_duration`. Since the + # read duration varies per batch (especially the first batch right after + # the file is opened), the measured emit interval can deviate from + # rate_period in either direction by roughly the same magnitude as the + # watcher scheduling delay. Use a symmetric jitter so the lower bound also + # tolerates this read/observation latency. + jitter = (tail_watcher_interval + sleep_interval) * safety_ratio + lower_interval = rate_period - jitter + upper_interval = rate_period + jitter emit_count = 0 prev_count = 0