[TT-11371] Move leaky-bucket behind the dev build flag (5.3.0)

[titpetric]

User description

https://tyktech.atlassian.net/browse/TT-11371

---

Type

enhancement, configuration changes

---

Description

• Moved the Leaky Bucket rate limiter configuration behind a development build flag.
• Removed the Leaky Bucket rate limiter option from the main configuration, making it exclusive to development builds.
• Updated tests and internal logic to reflect the removal of the Leaky Bucket rate limiter from the main configuration.
• Adjusted CLI linter schema to remove references to the now development-only Leaky Bucket rate limiter.

---

Changes walkthrough

	Relevant files
Enhancement	development.go Add Leaky Bucket Rate Limiter to Development Config            config/development.go Added EnableLeakyBucketRateLimiter configuration option to DevelopmentConfig. +9/-0
Configuration changes	rate_limit.go Remove Leaky Bucket Rate Limiter from Main Config                config/rate_limit.go Removed EnableLeakyBucketRateLimiter from RateLimit struct. Adjusted string representation logic for rate limiters. +0/-13    rate_nodev.go Adjust Rate Limiter Handling for Release Builds                    internal/rate/rate_nodev.go Removed Leaky Bucket rate limiter handling for release builds. +0/-3      schema.json Update CLI Linter Schema                                                                  cli/linter/schema.json Removed JSON schema entries related to Leaky Bucket rate limiter. +0/-9
Tests	mw_rate_limiting_test.go Update Rate Limiting Middleware Tests                                        gateway/mw_rate_limiting_test.go Removed test case setup for Leaky Bucket rate limiter. +0/-2

---

✨ PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[github-actions]

API Changes

--- prev.txt	2024-02-26 16:48:46.784954527 +0000
+++ current.txt	2024-02-26 16:48:44.020946839 +0000
@@ -5540,15 +5540,6 @@
     GetOAuthTokensPurgeInterval returns purge interval for lapsed OAuth tokens.
 
 type RateLimit struct {
-	// EnableLeakyBucketRateLimiter enables leaky bucket rate limiting.
-	//
-	// LeakyBucket will delay requests so they are processed in a FIFO
-	// style queue, ensuring a constant request rate and smoothing out
-	// traffic spikes. This comes at some cost to gateway instances, as
-	// the connections would be held for a longer time, instead of
-	// blocking the requests when they go over the defined rate limits.
-	EnableLeakyBucketRateLimiter bool `json:"enable_leaky_bucket_rate_limiter"`
-
 	// Redis based rate limiter with fixed window. Provides 100% rate limiting accuracy, but require two additional Redis roundtrip for each request.
 	EnableRedisRollingLimiter bool `json:"enable_redis_rolling_limiter"`
 

[github-actions]

PR Description updated to latest commit (f46d226)

[github-actions]

PR Review

⏱️ Estimated effort to review [1-5]	2, because the changes are straightforward and mostly involve configuration adjustments. The logic is not complex, but careful attention is needed to ensure that the feature toggle works as expected and that all references to the Leaky Bucket rate limiter are correctly handled.
🧪 Relevant tests	No
🔍 Possible issues	The removal of the Leaky Bucket rate limiter from the main configuration might impact existing deployments if they rely on this feature. It's important to communicate this change clearly in the release notes to avoid unexpected behavior after upgrading.
🔒 Security concerns	No

Code feedback:

---

relevant file	config/development.go
suggestion	Consider adding a default value for EnableLeakyBucketRateLimiter in the DevelopmentConfig struct to explicitly define the expected behavior when the field is not set. This can improve readability and prevent potential misunderstandings about the default state of the feature. [medium]
relevant line	EnableLeakyBucketRateLimiter bool `json:"enable_leaky_bucket_rate_limiter"`

---

relevant file	gateway/mw_rate_limiting_test.go
suggestion	Ensure that tests covering the Leaky Bucket rate limiter are updated or moved to a development-specific test suite. This is important to maintain test coverage for the feature while it's behind a development flag. [important]
relevant line	- globalConf.RateLimit.EnableLeakyBucketRateLimiter = true

---

relevant file	internal/rate/rate_nodev.go
suggestion	Add a comment explaining why the LimiterKind function in the rate_nodev.go file does not include the Leaky Bucket rate limiter. This will help maintainers understand the context and ensure that the development and production configurations are intentionally divergent. [medium]
relevant line	- if c.EnableLeakyBucketRateLimiter {

---

relevant file	cli/linter/schema.json
suggestion	Verify that the CLI linter's schema is updated in other places if necessary to reflect the removal of the Leaky Bucket rate limiter from the main configuration. This ensures consistency across the project's tooling. [medium]
relevant line	- "enable_leaky_bucket_rate_limiter": {

---

---

✨ Review tool usage guide:

---

Overview:
The review tool scans the PR code changes, and generates a PR review. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.
When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:

/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

With a configuration file, use the following template:

[pr_reviewer]
some_config1=...
some_config2=...

Utilizing extra instructions The review tool can be configured with extra instructions, which can be used to guide the model to a feedback tailored to the needs of your project. Be specific, clear, and concise in the instructions. With extra instructions, you are the prompter. Specify the relevant sub-tool, and the relevant aspects of the PR that you want to emphasize. Examples for extra instructions: [pr_reviewer] # /review # extra_instructions=""" In the 'possible issues' section, emphasize the following: - Does the code logic cover relevant edge cases? - Is the code logic clear and easy to understand? - Is the code logic efficient? ... """ Use triple quotes to write multi-line instructions. Use bullet points to make the instructions more readable.

How to enable\disable automation When you first install PR-Agent app, the default mode for the review tool is: pr_commands = ["/review", ...] meaning the review tool will run automatically on every PR, with the default configuration. Edit this field to enable/disable the tool, or to change the used configurations

Auto-labels The review tool can auto-generate two specific types of labels for a PR: a possible security issue label, that detects possible security issues (enable_review_labels_security flag) a Review effort [1-5]: x label, where x is the estimated effort to review the PR (enable_review_labels_effort flag)

Extra sub-tools The review tool provides a collection of possible feedbacks about a PR. It is recommended to review the possible options, and choose the ones relevant for your use case. Some of the feature that are disabled by default are quite useful, and should be considered for enabling. For example: require_score_review, require_soc2_ticket, and more.

Auto-approve PRs By invoking: /review auto_approve The tool will automatically approve the PR, and add a comment with the approval. To ensure safety, the auto-approval feature is disabled by default. To enable auto-approval, you need to actively set in a pre-defined configuration file the following: [pr_reviewer] enable_auto_approval = true (this specific flag cannot be set with a command line argument, only in the configuration file, committed to the repository) You can also enable auto-approval only if the PR meets certain requirements, such as that the estimated_review_effort is equal or below a certain threshold, by adjusting the flag: [pr_reviewer] maximal_review_effort = 5

More PR-Agent commands To invoke the PR-Agent, add a comment using one of the following commands: /review: Request a review of your Pull Request. /describe: Update the PR title and description based on the contents of the PR. /improve [--extended]: Suggest code improvements. Extended mode provides a higher quality feedback. /ask <QUESTION>: Ask a question about the PR. /update_changelog: Update the changelog based on the PR's contents. /add_docs 💎: Generate docstring for new components introduced in the PR. /generate_labels 💎: Generate labels for the PR based on the PR's contents. /analyze 💎: Automatically analyzes the PR, and presents changes walkthrough for each component. See the tools guide for more details. To list the possible configuration parameters, add a /config comment.

See the review usage page for a comprehensive guide on using this tool.

[github-actions]

PR Code Suggestions

	Suggestions
enhancement	Add a default value for the EnableLeakyBucketRateLimiter field.  Consider adding a default value for EnableLeakyBucketRateLimiter in the DevelopmentConfig struct to explicitly define the expected behavior when this field is not set. This can help avoid unexpected behavior in development environments. config/development.go [15] -EnableLeakyBucketRateLimiter bool `json:"enable_leaky_bucket_rate_limiter"` +EnableLeakyBucketRateLimiter bool `json:"enable_leaky_bucket_rate_limiter" default:"false"` Update the CLI linter schema to reflect the LeakyBucket rate limiter configuration change. After moving the LeakyBucket rate limiter configuration behind a development flag, ensure that the schema used by the CLI linter is updated accordingly. If there are specific validations or checks related to the LeakyBucket rate limiter, they should be adjusted to reflect its new context. cli/linter/schema.json [409-410] +"enable_leaky_bucket_rate_limiter": { + "type": "boolean", + "context": "development" +}, "enable_non_transactional_rate_limiter": { "type": "boolean" }
possible issue	Update tests related to the LeakyBucket rate limiter to reflect its new configuration. Since the LeakyBucket rate limiter configuration has been moved, ensure that any tests related to the LeakyBucket rate limiter are updated to reflect this change. If there are specific tests for the LeakyBucket rate limiter in development mode, they should be adjusted accordingly. gateway/mw_rate_limiting_test.go [244-245] +case "LeakyBucket": + // Ensure this test case is correctly configured for development mode default: t.Fatal("There is no such a rate limiter:", limiter) Adjust release build logic for the LeakyBucket rate limiter configuration change. Given that the LeakyBucket rate limiter configuration has been moved behind a development flag, ensure that any logic in release builds that previously depended on the LeakyBucket rate limiter being enabled or disabled is correctly adjusted. This might involve adding conditional logic based on build tags or other configuration flags. internal/rate/rate_nodev.go [13-14] +// Example: Conditional logic based on development build flag +if c.DevelopmentConfig.EnableLeakyBucketRateLimiter { + return "LeakyBucket", true +} return "", false
maintainability	Update documentation to reflect the LeakyBucket rate limiter configuration change. Ensure that any documentation or comments related to rate limiting configurations are updated to reflect the move of the LeakyBucket rate limiter behind a development flag. This helps maintain clarity and accuracy in the codebase. config/rate_limit.go [11] +// Note: LeakyBucket rate limiter is now a development-only feature. EnableRedisRollingLimiter bool `json:"enable_redis_rolling_limiter"`

---

✨ Improve tool usage guide:

---

Overview:
The improve tool scans the PR code changes, and automatically generates suggestions for improving the PR code. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on a PR.
When commenting, to edit configurations related to the improve tool (pr_code_suggestions section), use the following template:

/improve --pr_code_suggestions.some_config1=... --pr_code_suggestions.some_config2=...

With a configuration file, use the following template:

[pr_code_suggestions]
some_config1=...
some_config2=...

Enabling\disabling automation When you first install the app, the default mode for the improve tool is: pr_commands = ["/improve --pr_code_suggestions.summarize=true", ...] meaning the improve tool will run automatically on every PR, with summarization enabled. Delete this line to disable the tool from running automatically.

Utilizing extra instructions Extra instructions are very important for the improve tool, since they enable to guide the model to suggestions that are more relevant to the specific needs of the project. Be specific, clear, and concise in the instructions. With extra instructions, you are the prompter. Specify relevant aspects that you want the model to focus on. Examples for extra instructions: [pr_code_suggestions] # /improve # extra_instructions=""" Emphasize the following aspects: - Does the code logic cover relevant edge cases? - Is the code logic clear and easy to understand? - Is the code logic efficient? ... """ Use triple quotes to write multi-line instructions. Use bullet points to make the instructions more readable.

A note on code suggestions quality While the current AI for code is getting better and better (GPT-4), it's not flawless. Not all the suggestions will be perfect, and a user should not accept all of them automatically. Suggestions are not meant to be simplistic. Instead, they aim to give deep feedback and raise questions, ideas and thoughts to the user, who can then use his judgment, experience, and understanding of the code base. Recommended to use the 'extra_instructions' field to guide the model to suggestions that are more relevant to the specific needs of the project, or use the custom suggestions 💎 tool With large PRs, best quality will be obtained by using 'improve --extended' mode.

More PR-Agent commands To invoke the PR-Agent, add a comment using one of the following commands: /review: Request a review of your Pull Request. /describe: Update the PR title and description based on the contents of the PR. /improve [--extended]: Suggest code improvements. Extended mode provides a higher quality feedback. /ask <QUESTION>: Ask a question about the PR. /update_changelog: Update the changelog based on the PR's contents. /add_docs 💎: Generate docstring for new components introduced in the PR. /generate_labels 💎: Generate labels for the PR based on the PR's contents. /analyze 💎: Automatically analyzes the PR, and presents changes walkthrough for each component. See the tools guide for more details. To list the possible configuration parameters, add a /config comment.

See the improve usage page for a more comprehensive guide on using this tool.

[github-actions]

💥 CI tests failed 🙈

git-state

all ok

Please look at the run or in the Checks tab.

[github-actions]

💥 CI tests failed 🙈

git-state

all ok

Please look at the run or in the Checks tab.

[buger]

API tests result - postgres15-sha256 env: success ✅
Branch used: refs/tags/v5.3.0-rc2
Commit: 485ebf8
Triggered by: push (@sedkis)
Execution page

[buger]

API tests result - mongo44-sha256 env: success ✅
Branch used: refs/tags/v5.3.0-rc2
Commit: 485ebf8
Triggered by: push (@sedkis)
Execution page

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[titpetric]

/release to release-5.3

[tykbot]

Working on it! Note that it can take a few minutes.

[tykbot]

Still working...

[tykbot]

@titpetric Succesfully merged PR

[titpetric]

/release to release-5.3.0

[tykbot]

Working on it! Note that it can take a few minutes.

[tykbot]

@titpetric Succesfully merged PR

[buger]

API tests result - postgres15-murmur64 env: success ✅
Branch used: refs/tags/v5.3.0-rc2
Commit: 485ebf8
Triggered by: push (@sedkis)
Execution page

[buger]

API tests result - mongo44-murmur64 env: success ✅
Branch used: refs/tags/v5.3.0-rc2
Commit: 485ebf8
Triggered by: push (@sedkis)
Execution page