Skip to content

test(integration): unique client IPs for rate-limit tests - #77

Merged
santidev21 merged 1 commit into
mainfrom
fix/rate-limit-test-flake
Oct 6, 2026
Merged

santidev21 merged 1 commit into
mainfrom
fix/rate-limit-test-flake

Conversation

@santidev21

Copy link
Copy Markdown
Owner

Problem

RateLimitIntegrationTests chose 203.0.113.{1..253} at random; AuthorizationIntegrationTests pinned 203.0.113.250. When the random draw landed on 250 the two shared a per-IP limiter partition, so the rate-limit test began with part of its budget spent and failed intermittently — observed on the release PR #72: 6 of the first 10 requests were already 429.

Fix

New TestClientIps.Next() (a thread-safe counter in the 198.18.0.0/15 benchmarking range) hands out a unique IP per call. Both tests use it, so partitions can never collide. Verified locally: RateLimitIntegrationTests + AuthorizationIntegrationTests pass (6/6).

This is a test-only, deterministic fix; no production code changed.

RateLimitIntegrationTests picked `203.0.113.{1..253}` at random while
AuthorizationIntegrationTests pinned `203.0.113.250`. When the random draw hit
250 the two shared a limiter partition, so the rate-limit test started with
part of its budget spent and failed intermittently (observed: 6/10 requests
already 429). Replace both with a sequence-based helper that hands out a unique
IP per call, so partitions can never collide.
@sonarqubecloud

sonarqubecloud Bot commented Oct 6, 2026

Copy link
Copy Markdown

@santidev21
santidev21 merged commit 4a9f6a1 into main Oct 6, 2026
14 checks passed
@santidev21
santidev21 deleted the fix/rate-limit-test-flake branch October 6, 2026 16:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant