web: reload the rate limiter when its configuration changes - #442
Open
mrueg wants to merge 1 commit into
Open
Conversation
The documentation says the configuration file "is read upon every http request", and users, headers and certificates behave that way. The rate limiter did not: it was built once when the server started and captured in the handler, so editing rate_limit had no effect until a restart, with nothing in the logs to say so. Removing the section entirely did not lift the limit either. Build the limiter from the configuration the handler has just read, keeping the existing one while the values are unchanged. Rebuilding on every request would hand out a fresh burst each time and defeat the limit entirely, so the limiter is replaced only when interval or burst actually change, and the change is logged. Replacing the limiter resets its token bucket, so a change to rate_limit starts the interval afresh. That is now stated in the documentation. The limiter is still built once at startup so that an enabled rate limiter is reported in the logs there as it was before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Manuel Rüger <manuel@rueg.eu>
mrueg
force-pushed
the
fix/rate-limit-hot-reload
branch
from
September 2, 2026 13:44
11599d9 to
633968b
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
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.
The documentation says the configuration file "is read upon every http request", and users, headers and certificates behave that way. The rate limiter does not: it is built once when the server starts and captured in the handler, so editing
rate_limithas no effect until a restart, with nothing in the logs to say so. Removing the section entirely does not lift the limit either.Reproduced against master: started with
burst: 1, interval: 1h, rewrote the file to removerate_limit, and the next requests still returned 200 then 429.Change
Build the limiter from the configuration the handler has just read, keeping the existing one while the values are unchanged. Rebuilding on every request would hand out a fresh burst each time and defeat the limit entirely, so the limiter is replaced only when
intervalorburstactually change, and the change is logged.Replacing the limiter resets its token bucket, so a change to
rate_limitstarts the interval afresh — now stated in the docs. The limiter is still built once at startup so that an enabled rate limiter is reported in the logs there as before.Tests
An end-to-end test that limits, lifts the limit by rewriting the file, and re-applies it; it fails against master at the first step after the rewrite. Plus a unit test that an unchanged configuration keeps the same limiter instance.
🤖 Generated with Claude Code