Problem
Several FastAPI contrib tests use per-second quotas while asserting immediate exhaustion or exact remaining counts.
Under a loaded pytest -n auto run, more than one second can elapse between requests. The quota can then refill and make the test return 200 instead of the expected 429.
This occurred on Python 3.13 in PR #173:
TestLimiterLimit.test_limit__per_route_key_func__overrides_default- The second
/shared request was expected to return 429 but returned 200.
The same timing dependency also appears in FastAPI tests covering response headers, hooks, store backends, and limiter algorithms.
Proposal
Audit the FastAPI contrib tests that rely on per-second quotas. When a test does not specifically verify refill timing, use a longer window such as /m.
This follows the approach already applied to the Flask contrib tests in commit b7cec82.
After updating the tests, run the FastAPI suite repeatedly with pytest -n auto on Python 3.10 through 3.14.
Problem
Several FastAPI contrib tests use per-second quotas while asserting immediate exhaustion or exact remaining counts.
Under a loaded
pytest -n autorun, more than one second can elapse between requests. The quota can then refill and make the test return 200 instead of the expected 429.This occurred on Python 3.13 in PR #173:
TestLimiterLimit.test_limit__per_route_key_func__overrides_default/sharedrequest was expected to return 429 but returned 200.The same timing dependency also appears in FastAPI tests covering response headers, hooks, store backends, and limiter algorithms.
Proposal
Audit the FastAPI contrib tests that rely on per-second quotas. When a test does not specifically verify refill timing, use a longer window such as
/m.This follows the approach already applied to the Flask contrib tests in commit
b7cec82.After updating the tests, run the FastAPI suite repeatedly with
pytest -n autoon Python 3.10 through 3.14.