feat: preserve rate limiters in memory across configuration reloads #1792
Conversation
This file contains 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
The goal with this change is to persist the rate limiters across reloads with the least invasive changes possible. To do this I first added a LimiterOptions structure to hold the current set of rate limiters. I then identified each call of tollbooth.New and moved the construction of the limiter without modifications to options.go. I assigned each limiter a distinct field to be referenced during the API object creation. Next I needed to add an optional parameter to the NewAPI methods so I could store the new LimiterOptions onto the API object for reference during route construction. To do this without breaking all existing calls to NewAPI I used the options pattern. This makes the method accept a parametric set of values implementing a common interface, so future problems of similar nature can also be added as options. I then replaced all the local anonymous limiter.Limiters made inline within the API route construction with each corresponding newly added field within the LimiterOptions struct.
Pull Request Test Coverage Report for Build 11244024882Details
💛 - Coveralls |
hf
approved these changes
Oct 10, 2024
There was a problem hiding this comment.
Maybe change the title to say "preservation" or similar instead of "persistence." The latter to me sounds like its getting persisted somewhere (disk, database, etc.) when in fact this just preserves the values across config changes.
Titles are important as they show up in the changelog.
|
Also feel free to remove the headings from the PR description -- those are mostly to guide external contributors. |
cstockton
changed the title
cstockton
pushed a commit
that referenced
this pull request
Oct 15, 2024
🤖 I have created a release *beep* *boop* --- ## [2.163.0](v2.162.2...v2.163.0) (2024-10-15) ### Features * add mail header support via `GOTRUE_SMTP_HEADERS` with `$messageType` ([#1804](#1804)) ([99d6a13](99d6a13)) * add MFA for WebAuthn ([#1775](#1775)) ([8cc2f0e](8cc2f0e)) * configurable email and sms rate limiting ([#1800](#1800)) ([5e94047](5e94047)) * mailer logging ([#1805](#1805)) ([9354b83](9354b83)) * preserve rate limiters in memory across configuration reloads ([#1792](#1792)) ([0a3968b](0a3968b)) ### Bug Fixes * add twilio verify support on mfa ([#1714](#1714)) ([aeb5d8f](aeb5d8f)) * email header setting no longer misleading ([#1802](#1802)) ([3af03be](3af03be)) * enforce authorized address checks on send email only ([#1806](#1806)) ([c0c5b23](c0c5b23)) * fix `getExcludedColumns` slice allocation ([#1788](#1788)) ([7f006b6](7f006b6)) * Fix reqPath for bypass check for verify EP ([#1789](#1789)) ([646dc66](646dc66)) * inline mailme package for easy development ([#1803](#1803)) ([fa6f729](fa6f729)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 goal with this change is to persist the rate limiters across reloads with the least invasive changes possible. To do this I first added a LimiterOptions structure to hold the current set of rate limiters. I then identified each call of tollbooth.New and moved the construction of the limiter without modifications to options.go. I assigned each limiter a distinct field to be referenced during the API object creation.
Next I needed to add an optional parameter to the NewAPI methods so I could store the new LimiterOptions onto the API object for reference during route construction. To do this without breaking all existing calls to NewAPI I used the options pattern. This makes the method accept a parametric set of values implementing a common interface, so future problems of similar nature can also be added as options.
I then replaced all the local anonymous limiter.Limiters made inline within the API route construction with each corresponding newly added field within the LimiterOptions struct.
What kind of change does this PR introduce?
Feature
What is the current behavior?
Currently we do not persist rate limiters when the config is reloaded.
What is the new behavior?
We persist rate limiters in memory across configuration reloads.