From dc4e86f4d140ed971f5c40e1e74f6617ac889d02 Mon Sep 17 00:00:00 2001 From: Shizuo Fujita Date: Sun, 6 Sep 2026 14:51:59 +0900 Subject: [PATCH] test_in_tail: fix flaky throttling test by allowing one extra watcher tick The `test "lines collected with throttling"` still fails intermittently on CI, this time on the upper bound: elapsed_seconds 3.329012749999947 is out of allowed range: lower: 0.6799999999999999 [sec] upper: 3.3200000000000003 [sec]. The throttling state is re-checked only when the tail watcher is notified. Once the file has been fully written, retries depend mainly on the 1s timer tick. 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 + 1s after the previous one. The existing jitter (1.32s) already contains one watcher interval, but that allowance is shared with the read/observation latency: when the extra tick and a slow batch coincide, only 0.32s is left for the read-time skew and the 0.1s polling of the test thread, which is not enough on a slow runner. Add the watcher interval to the upper bound explicitly, so the upper bound tolerates the same read/observation latency as the lower bound on top of the extra tick. The per-cycle line-count assertion is kept, so a regression that actually breaks throttling is still detected. Co-Authored-By: Claude Fable 5.1 Signed-off-by: Shizuo Fujita --- 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 036315846f..0819708eee 100644 --- a/test/plugin/test_in_tail.rb +++ b/test/plugin/test_in_tail.rb @@ -2791,9 +2791,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