test: a refilled token-bucket burst after idle is admitted in full

[dittops]

Summary

Two real-Redis regression tests for the token bucket's refilled burst after a drain: a limit of 1/s with burst 2 must admit exactly 2 once the bucket has refilled.

• a_concurrent_burst_after_idle_gets_the_whole_burst: one replica, local_allowance 0.8, a 10 ms Redis timeout, store latency of 0, 2 and 4 ms, 6 rounds. A burst of 5 drains the bucket; 2.6 s later a burst of 3 must get exactly 2.
• a_staggered_burst_after_idle_gets_the_whole_burst_with_a_second_window: the same bucket plus a per-minute window that never binds (1000, 3000 or 6000/min). A token bucket gives every window the burst. Requests arrive 0, 1, 3 or 8 ms apart, the way traffic does through a load balancer. The second window must not cost the refilled burst a token.

These tests were written while chasing an apparent under-admission on a live gateway. That turned out to be a timing artifact in the calling test: a response cache answered the repeated request in about 0.5 s, so the measured gap from the drain was shorter than intended. The limiter admitted correctly. These tests pin that behaviour down. No library code changes.

Test plan

• cargo fmt --check
• cargo clippy --all-targets --features redis-0-31 -- -D warnings, and the same with redis-0-27
• RESIL_TEST_REDIS_URL=redis://127.0.0.1:6390 cargo test --release --features redis-0-31: 54 + 5 + 4 + 17 passed

Note: the staggered test sleeps 2.6 s per round over 12 configurations, which adds about 2 minutes to the Redis test job.

🤖 Generated with Claude Code