Skip to content

Merging to release-5.3.0: TT-11485, fix for global rate limit disabled flag not working (#6120)#6128

Merged
andrei-tyk merged 1 commit into
release-5.3.0from
merge/release-5.3.0/53886d044c43930b332dbe4a73cf727069df0770
Mar 8, 2024
Merged

Merging to release-5.3.0: TT-11485, fix for global rate limit disabled flag not working (#6120)#6128
andrei-tyk merged 1 commit into
release-5.3.0from
merge/release-5.3.0/53886d044c43930b332dbe4a73cf727069df0770

Conversation

@buger

@buger buger commented Mar 8, 2024

Copy link
Copy Markdown
Member

User description

TT-11485, fix for global rate limit disabled flag not working (#6120)

User description

Description

Related Issue

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing
    functionality to change)
  • Refactoring or add test (improvements in base code or adds test
    coverage to functionality)

Checklist

  • I ensured that the documentation is up to date
  • I explained why this PR updates go.mod in detail with reasoning
    why it's required
  • I would like a code coverage CI quality gate exception and have
    explained why

Type

Bug fix


Description

  • Fixed an issue where the global rate limit disabled flag was not
    properly checked, causing the rate limiter to be incorrectly enabled.

Changes walkthrough

Relevant files
Bug fix
mw_api_rate_limit.go
Fix Global Rate Limit Disabled Flag Check                               

gateway/mw_api_rate_limit.go

  • Added a condition to check GlobalRateLimit.Disabled flag in
    EnabledForSpec function.
  • +1/-1     

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


    Type

    Bug fix, Tests


    Description

    • Added a missing condition to properly check if the global rate limit is disabled in the EnabledForSpec function.
    • Introduced a new test case to ensure the EnabledForSpec function respects the GlobalRateLimit.Disabled flag.

    Changes walkthrough

    Relevant files
    Bug fix
    mw_api_rate_limit.go
    Fix Global Rate Limit Disabled Flag Check                               

    gateway/mw_api_rate_limit.go

  • Added a condition to check if GlobalRateLimit.Disabled is true in the
    EnabledForSpec function.
  • +1/-1     
    Tests
    mw_api_rate_limit_test.go
    Add Test for Global Rate Limit Disabled Flag                         

    gateway/mw_api_rate_limit_test.go

  • Imported apidef and assert packages for testing.
  • Added a new test TestRateLimitForAPI_EnabledForSpec to verify the
    correct behavior of the EnabledForSpec function when the global rate
    limit is disabled.
  • +11/-0   

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

    ## **User description**
    <!-- Provide a general summary of your changes in the Title above -->
    
    ## Description
    
    <!-- Describe your changes in detail -->
    
    ## Related Issue
    
    <!-- This project only accepts pull requests related to open issues. -->
    <!-- If suggesting a new feature or change, please discuss it in an
    issue first. -->
    <!-- If fixing a bug, there should be an issue describing it with steps
    to reproduce. -->
    <!-- OSS: Please link to the issue here. Tyk: please create/link the
    JIRA ticket. -->
    
    ## Motivation and Context
    
    <!-- Why is this change required? What problem does it solve? -->
    
    ## How This Has Been Tested
    
    <!-- Please describe in detail how you tested your changes -->
    <!-- Include details of your testing environment, and the tests -->
    <!-- you ran to see how your change affects other areas of the code,
    etc. -->
    <!-- This information is helpful for reviewers and QA. -->
    
    ## Screenshots (if appropriate)
    
    ## Types of changes
    
    <!-- What types of changes does your code introduce? Put an `x` in all
    the boxes that apply: -->
    
    - [ ] Bug fix (non-breaking change which fixes an issue)
    - [ ] New feature (non-breaking change which adds functionality)
    - [ ] Breaking change (fix or feature that would cause existing
    functionality to change)
    - [ ] Refactoring or add test (improvements in base code or adds test
    coverage to functionality)
    
    ## Checklist
    
    <!-- Go over all the following points, and put an `x` in all the boxes
    that apply -->
    <!-- If there are no documentation updates required, mark the item as
    checked. -->
    <!-- Raise up any additional concerns not covered by the checklist. -->
    
    - [ ] I ensured that the documentation is up to date
    - [ ] I explained why this PR updates go.mod in detail with reasoning
    why it's required
    - [ ] I would like a code coverage CI quality gate exception and have
    explained why
    
    
    ___
    
    ## **Type**
    Bug fix
    
    
    ___
    
    ## **Description**
    - Fixed an issue where the global rate limit disabled flag was not
    properly checked, causing the rate limiter to be incorrectly enabled.
    
    
    ___
    
    
    
    ## **Changes walkthrough**
    <table><thead><tr><th></th><th align="left">Relevant
    files</th></tr></thead><tbody><tr><td><strong>Bug
    fix</strong></td><td><table>
    <tr>
      <td>
        <details>
    <summary><strong>mw_api_rate_limit.go</strong><dd><code>Fix Global Rate
    Limit Disabled Flag Check</code>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
    &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
    &nbsp; </dd></summary>
    <hr>
    
    gateway/mw_api_rate_limit.go
    <li>Added a condition to check <code>GlobalRateLimit.Disabled</code>
    flag in <br><code>EnabledForSpec</code> function.<br>
    
    
    </details>
        
    
      </td>
    <td><a
    href="https://github.com/TykTechnologies/tyk/pull/6120/files#diff-46326b04f936c839922e970db5c2924156cc797070948f3dc9c589d04661d6d2">+1/-1</a>&nbsp;
    &nbsp; &nbsp; </td>
    </tr>                    
    </table></td></tr></tr></tbody></table>
    
    ___
    
    > ✨ **PR-Agent usage**:
    >Comment `/help` on the PR to get a list of all available PR-Agent tools
    and their descriptions
    
    (cherry picked from commit 53886d0)
    @github-actions

    github-actions Bot commented Mar 8, 2024

    Copy link
    Copy Markdown
    Contributor

    PR Description updated to latest commit (4daef3b)

    @github-actions

    github-actions Bot commented Mar 8, 2024

    Copy link
    Copy Markdown
    Contributor

    PR Review

    ⏱️ Estimated effort to review [1-5]

    2, because the changes are straightforward and localized to a specific functionality, but require understanding of the rate limiting feature and its implications.

    🧪 Relevant tests

    Yes

    🔍 Possible issues

    Possible Bug: The condition k.Spec.GlobalRateLimit.Rate == 0 || k.Spec.GlobalRateLimit.Disabled might lead to unexpected behavior if GlobalRateLimit.Rate is intentionally set to 0 to disable rate limiting, but GlobalRateLimit.Disabled is false. Consider clarifying the precedence of these flags or ensuring they cannot be misconfigured.

    🔒 Security concerns

    No

    Code feedback:
    relevant filegateway/mw_api_rate_limit.go
    suggestion      

    Consider adding a comment explaining the precedence and intended use of DisableRateLimit, GlobalRateLimit.Rate, and GlobalRateLimit.Disabled to avoid confusion and potential misconfiguration. [important]

    relevant lineif k.Spec.DisableRateLimit || k.Spec.GlobalRateLimit.Rate == 0 || k.Spec.GlobalRateLimit.Disabled {

    relevant filegateway/mw_api_rate_limit_test.go
    suggestion      

    Add more test cases for EnabledForSpec to cover scenarios where DisableRateLimit and GlobalRateLimit.Rate are set to different values, including edge cases. This ensures comprehensive testing of the logic changes. [important]

    relevant linefunc TestRateLimitForAPI_EnabledForSpec(t *testing.T) {


    ✨ 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

    github-actions Bot commented Mar 8, 2024

    Copy link
    Copy Markdown
    Contributor

    PR Code Suggestions

    CategorySuggestions                                                                                                                                                       
    Maintainability
    Simplify the conditional check by encapsulating logic in a method.

    Consider simplifying the conditional check by combining the conditions related to
    GlobalRateLimit into a single method call. This will improve readability and
    maintainability of your code. For instance, you could add a method
    IsGlobalRateLimitDisabled() to the GlobalRateLimit struct that encapsulates the logic of
    checking if the rate limit is disabled either by rate being 0 or the disabled flag being
    true.

    gateway/mw_api_rate_limit.go [29]

    -if k.Spec.DisableRateLimit || k.Spec.GlobalRateLimit.Rate == 0 || k.Spec.GlobalRateLimit.Disabled {
    +if k.Spec.DisableRateLimit || k.Spec.GlobalRateLimit.IsGlobalRateLimitDisabled() {
       return false
     }
     
    Enhancement
    Add more test cases for comprehensive testing of the EnabledForSpec method.

    To ensure comprehensive testing, consider adding more test cases for the EnabledForSpec
    method. Specifically, test scenarios where the rate limit is enabled, and when the rate is
    non-zero but the disabled flag is true. This will help ensure that the logic handles all
    possible configurations correctly.

    gateway/mw_api_rate_limit_test.go [71-75]

    -func TestRateLimitForAPI_EnabledForSpec(t *testing.T) {
    -  apiSpecDisabled := APISpec{APIDefinition: &apidef.APIDefinition{GlobalRateLimit: apidef.GlobalRateLimit{Disabled: true, Rate: 2, Per: 1}}}
    +// Additional test cases should be added here
     
    -  rlDisabled := &RateLimitForAPI{BaseMiddleware: &BaseMiddleware{Spec: &apiSpecDisabled}}
    -  assert.False(t, rlDisabled.EnabledForSpec())
    -}
    -

    ✨ 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

    github-actions Bot commented Mar 8, 2024

    Copy link
    Copy Markdown
    Contributor

    API Changes

    no api changes detected

    @github-actions

    github-actions Bot commented Mar 8, 2024

    Copy link
    Copy Markdown
    Contributor

    💥 CI tests failed 🙈

    git-state

    all ok

    Please look at the run or in the Checks tab.

    @buger

    buger commented Mar 8, 2024

    Copy link
    Copy Markdown
    Member Author

    API tests result - postgres15-sha256 env: success
    Branch used: refs/tags/v5.3.0-rc6
    Commit: b9375e3
    Triggered by: push (@ilijabojanovic)
    Execution page

    @buger

    buger commented Mar 8, 2024

    Copy link
    Copy Markdown
    Member Author

    API tests result - mongo44-sha256 env: success
    Branch used: refs/tags/v5.3.0-rc6
    Commit: b9375e3
    Triggered by: push (@ilijabojanovic)
    Execution page

    @sonarqubecloud

    sonarqubecloud Bot commented Mar 8, 2024

    Copy link
    Copy Markdown

    @andrei-tyk
    andrei-tyk merged commit b9375e3 into release-5.3.0 Mar 8, 2024
    @andrei-tyk
    andrei-tyk deleted the merge/release-5.3.0/53886d044c43930b332dbe4a73cf727069df0770 branch March 8, 2024 12:18
    @buger

    buger commented Mar 8, 2024

    Copy link
    Copy Markdown
    Member Author

    API tests result - postgres15-murmur64 env: success
    Branch used: refs/tags/v5.3.0-rc6
    Commit: b9375e3
    Triggered by: push (@ilijabojanovic)
    Execution page

    @buger

    buger commented Mar 8, 2024

    Copy link
    Copy Markdown
    Member Author

    API tests result - mongo44-murmur64 env: success
    Branch used: refs/tags/v5.3.0-rc6
    Commit: b9375e3
    Triggered by: push (@ilijabojanovic)
    Execution page

    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Projects

    None yet

    Development

    Successfully merging this pull request may close these issues.

    2 participants