Rate limits that allow for bursts and protect sensitive endpoints#42
Merged
Conversation
eyeseast
reviewed
Jun 15, 2026
eyeseast
approved these changes
Jun 15, 2026
mitchelljkotler
requested changes
Jun 15, 2026
mitchelljkotler
left a comment
mitchelljkotler
left a comment
Member
There was a problem hiding this comment.
Would also be good to have some tests for the new rate limiting behavior
duckduckgrayduck
force-pushed
the
rate_limits
branch
from
3c4b7de to
0c18b54
Compare
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
3 participants
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.
This creates some rate limits for endpoints especially sensitive to scripts where the user has set no rate limiting of their own that use our official libraries. We should set a good example of rate limiting by doing it for them in the client. The only thing that doesn't use the client because it is hosted on s3.documentcloud.org (this is for fetching assets of public documents) has to be configured in a separate rate limiter in documents.py. I feel that this is an acceptable tradeoff. I have tried these locally and believe they offer a good balance for someone wanting to do a small workflow quickly, but won't affect our services long term. This uses the token-bucket library: https://pypi.org/project/token-bucket/
python-muckrock will receive the same update.
I noticed that there was a custom user agent set for calls to s3.documentcloud.org, this also sets that to the one we should use from the client.