chore: remove the dead DRF throttle config that misled a diagnosis - #143
Merged
Conversation
DEFAULT_THROTTLE_RATES was set to {"anon": "100/hour", "user":
"1000/hour"} and had no effect whatsoever: DEFAULT_THROTTLE_CLASSES was
never configured, no view declares throttle_classes, and the endpoint
that actually gets hammered (/api/graphql) is a Strawberry view, not a
DRF one.
It was not merely inert. While diagnosing a flood of 429s on 2026-09-03
it was the first thing found, read as the cause, and very nearly
"fixed" - a change that would have altered nothing while sending the
investigation the wrong way.
Replaced with a comment pointing at api/middleware/rate_limit.py, which
is what actually runs: 5000/hour for GET, 1000/hour for other methods,
keyed on the client IP from X-Forwarded-For.
No behaviour change - the setting was doing nothing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No behaviour change — the setting was doing nothing.
This had no effect whatsoever:
DEFAULT_THROTTLE_CLASSESwas never configuredthrottle_classes/api/graphql, the endpoint that actually gets hammered, is a Strawberry view rather than a DRF oneWhy remove it rather than leave it
It was not merely inert. While diagnosing a flood of 429s on 2026-09-03 it was the first thing found, read as the cause, and very nearly "fixed" — a change that would have altered nothing while sending the investigation off in the wrong direction. Config that looks like it governs behaviour but does not is worse than no config.
Replaced with a comment pointing at what actually runs:
api/middleware/rate_limit.py(registered inMIDDLEWARE), 5000/hour for GET and 1000/hour for other methods, keyed on the client IP fromX-Forwarded-For.Note on the limits themselves
Left unchanged deliberately. 1000/hour for non-GET is reasonable; the incident was caused by a frontend loop issuing 6,230 requests per minute (DataSpaceFrontend#453), not by the limit being too low. Raising it would only have let a runaway client do more damage.
Worth a separate look: the limit is keyed per IP, so everyone behind a NAT gateway shares one budget — which is why a single broken client took out every other user at that address.