From acbac65547c11f9579c17bc855b66782cf03a512 Mon Sep 17 00:00:00 2001 From: Shizuo Fujita Date: Mon, 7 Sep 2026 15:27:55 +0900 Subject: [PATCH] test_in_tail: fix flaky throttling test by allowing one extra watcher tick (#5489) 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 `lines collected with throttling` test still fails intermittently after #5381 and #5418, this time on the upper bound: [Ruby 3.3 on macOS CI](https://github.com/fluent/fluentd/actions/runs/34003950778/job/101426224818) measured 3.329s against a 3.32s limit. ``` 4) Failure: test: lines collected with throttling(TailInputTest::throttling logs at in_tail level): elapsed_seconds 3.329012749999947 is out of allowed range: lower: 0.6799999999999999 [sec] upper: 3.3200000000000003 [sec]. ``` Once the file has been written, retries depend mainly on the 1s watcher timer. A tick near the 2s rate-period boundary can arrive slightly too early, delaying the next read until the following tick. Local tracing confirmed read-start intervals of both approximately 2s and 3s. The existing 1.32s allowance covers both timer scheduling and read/observation latency. When an extra tick consumes 1s, only 0.32s remains for other delays—slightly less than this CI run needed. This PR adds one watcher interval to the upper bound, increasing it from 3.32s to 4.32s. The lower bound and record-count assertions remain unchanged. **Docs Changes**: N/A **Release Note**: N/A Signed-off-by: Shizuo Fujita Co-authored-by: Claude Fable 5.1 Signed-off-by: github-actions[bot] --- test/plugin/test_in_tail.rb | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/test/plugin/test_in_tail.rb b/test/plugin/test_in_tail.rb index 29b4ff2c8e..ad720530df 100644 --- a/test/plugin/test_in_tail.rb +++ b/test/plugin/test_in_tail.rb @@ -2783,9 +2783,21 @@ def test_lines_collected_with_no_throttling(data) # 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. + # + # In addition, the throttling state is re-checked only when the watcher + # is notified. Once the file has been fully written, no further stat + # change is expected, so retries depend mainly on the timer notification + # (every tail_watcher_interval). Whether the tick that lands exactly + # rate_period after the previous read start already satisfies + # `time_spent >= rate_period` depends on sub-millisecond scheduling + # differences, so the next read can start one tick later, i.e. + # rate_period + tail_watcher_interval after the previous one. The jitter + # above already contains one tail_watcher_interval, but that allowance is + # shared with the read/observation latency. When the extra tick and a + # slow batch coincide, the sum exceeds it, so add one tick explicitly. jitter = (tail_watcher_interval + sleep_interval) * safety_ratio lower_interval = rate_period - jitter - upper_interval = rate_period + jitter + upper_interval = rate_period + tail_watcher_interval + jitter emit_count = 0 prev_count = 0