Problem
slowapi.Limiter is used as a module-level singleton in our FastAPI application because @limiter.limit(...) captures self at decoration time. To reconfigure the limiter per-app — for example, to rebuild storage so tests running two FastAPI apps in the same process do not share counters — we currently mutate the private attributes _storage and _limiter. This couples our code to slowapi internals.
Ask
Would you consider exposing one of the following so callers do not have to touch private attributes:
- An app-state-aware decoration path — a documented way for
@limiter.limit(...) to defer to the Limiter instance attached to request.app.state.limiter (which SlowAPIMiddleware already resolves for enforcement), so the module-level singleton becomes purely a metadata holder.
- A public
Limiter.rebind_from(other: Limiter) method that handles the storage + rate-limit engine swap atomically.
Either would let us drop the private-attribute mutation we currently rely on.
Workaround
We isolate the mutation behind a single helper so any rename surfaces in one diff, log loudly on AttributeError, and pin slowapi<0.2.0 in our lockfile as defence in depth.
Why this matters
The current pattern works, but every dependency bump is a potential silent break of test isolation between FastAPI apps sharing a process. A blessed public hook would let downstream projects drop their workarounds.
Happy to help with a PR if either direction sounds reasonable.
Problem
slowapi.Limiteris used as a module-level singleton in our FastAPI application because@limiter.limit(...)capturesselfat decoration time. To reconfigure the limiter per-app — for example, to rebuild storage so tests running two FastAPI apps in the same process do not share counters — we currently mutate the private attributes_storageand_limiter. This couples our code to slowapi internals.Ask
Would you consider exposing one of the following so callers do not have to touch private attributes:
@limiter.limit(...)to defer to theLimiterinstance attached torequest.app.state.limiter(whichSlowAPIMiddlewarealready resolves for enforcement), so the module-level singleton becomes purely a metadata holder.Limiter.rebind_from(other: Limiter)method that handles the storage + rate-limit engine swap atomically.Either would let us drop the private-attribute mutation we currently rely on.
Workaround
We isolate the mutation behind a single helper so any rename surfaces in one diff, log loudly on
AttributeError, and pinslowapi<0.2.0in our lockfile as defence in depth.Why this matters
The current pattern works, but every dependency bump is a potential silent break of test isolation between FastAPI apps sharing a process. A blessed public hook would let downstream projects drop their workarounds.
Happy to help with a PR if either direction sounds reasonable.