[TT-14402] Add Handler for Gateway Storage MaxIdle Config #429

LLe27 · 2025-10-03T13:27:16Z

Description

Add the flexibility to configure the Tyk Gateway configuration TYK_GW_STORAGE_MAXIDLE value in the Tyk-Charts.

Related Issue

TT-14402 - Setting TYK_GW_STORAGE_MAXIDLE in Helm Charts leads to duplicate config error

Motivation and Context

Test Coverage For This Change

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)
Documentation updates or improvements.

Checklist

Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If PRing from your fork, don't come from your master!
Make sure you are making a pull request against our master branch (left side). Also, it would be best if you started your change off our latest master.
My change requires a change to the documentation.
- I have manually updated the README(s)/documentation accordingly.
I have updated the documentation accordingly.
I have added tests to cover my changes.
All new and existing tests passed.

probelabs · 2025-10-03T13:33:16Z

🔍 Code Analysis Results

Pull Request Analysis: TT-14402 Add Handler for Gateway Storage MaxIdle Config

This pull request introduces a new configuration option to the Tyk Helm charts, allowing users to customize the maximum number of idle connections in the Redis connection pool for the Tyk Gateway.

1. Change Impact Analysis

What this PR Accomplishes

This PR addresses the inability to easily configure the TYK_GW_STORAGE_MAXIDLE setting in the Tyk Gateway via Helm charts. Previously, this value was hardcoded, and attempts to override it could lead to duplicate configuration errors. By exposing this setting as a configurable value, users can now fine-tune the Gateway's Redis connection pool to better suit their specific performance and resource requirements.

Key Technical Changes Introduced

New Configuration Parameter: A new parameter, global.redis.maxIdle, has been added to the values.yaml files for the following charts:
- tyk-gateway
- tyk-control-plane
- tyk-data-plane
- tyk-oss
- tyk-stack
This parameter is set to a default value of 1000.
Deployment Template Update: The gateway deployment template (components/tyk-gateway/templates/deployment-gw-repset.yaml) has been modified. The environment variable TYK_GW_STORAGE_MAXIDLE is no longer hardcoded. Instead, it now dynamically pulls its value from {{ default "100" .Values.global.redis.maxIdle }}. This ensures that the value from the values.yaml file is used, with a safe fallback to "100" if the parameter is not defined.

Affected System Components

Tyk Gateway: The primary component affected. The behavior of its Redis connection pool is now configurable, which can impact performance, resource usage, and resilience.
Helm Chart Configuration: Users deploying Tyk via the affected Helm charts will have a new value to manage in their values.yaml files. This is a non-breaking change that adds new functionality.

2. Architecture Visualization

The following diagram illustrates how the new configuration parameter flows from the Helm values.yaml file to the running Tyk Gateway container.

graph TD
    subgraph "Helm Chart Deployment"
        A["values.yaml <br> (e.g., tyk-stack/values.yaml)"] --|Defines `.Values.global.redis.maxIdle`|--> B["templates/deployment-gw-repset.yaml"];
    end

    B --|Helm renders template into|--> C["Kubernetes Deployment Manifest"];
    
    subgraph "Kubernetes Cluster"
        C --|Creates|--> D["Gateway Pod"];
    end

    subgraph "Gateway Pod"
        D --|Contains|--> E["Container Spec"];
        E --|Defines Env Var|--> F["TYK_GW_STORAGE_MAXIDLE={{ .Values.global.redis.maxIdle }}"];
    end
    
    F --|Read by|--> G["Tyk Gateway Process"];

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style B fill:#ccf,stroke:#333,stroke-width:2px
    style G fill:#bbf,stroke:#333,stroke-width:2px

Diagram Explanation:

The user defines the global.redis.maxIdle value in their values.yaml file.
During helm install or helm upgrade, the Helm templating engine reads this value and injects it into the Gateway's Kubernetes Deployment manifest (deployment-gw-repset.yaml).
Kubernetes creates a new Gateway Pod based on this manifest.
The Pod's container is started with the TYK_GW_STORAGE_MAXIDLE environment variable set to the value provided by the user.
The Tyk Gateway process reads this environment variable on startup to configure its Redis connection pool.

Powered by Visor from Probelabs

Last updated: 2025-10-03T13:55:59.388Z | Triggered by: synchronize | Commit: 59ed8aa

probelabs · 2025-10-03T13:33:17Z

🔍 Code Analysis Results

Security Issues (2)

Severity	Location	Issue
🟡 Warning	`components/tyk-gateway/values.yaml:131`	The newly introduced `global.redis.maxIdle` parameter lacks validation to prevent excessively high values. A user misconfiguration could lead to resource exhaustion on the Tyk Gateway or the Redis server by maintaining a large number of idle connections, potentially causing a Denial of Service. 💡 Suggestion It is recommended to add validation for this input. While Helm's validation capabilities are limited, you could use the `fail` function within the template to enforce a sensible upper limit. For example, adding this to `deployment-gw-repset.yaml`: {{- if gt (int .Values.global.redis.maxIdle) 5000 -}} {{- fail "Error: global.redis.maxIdle must not exceed 5000 to prevent resource exhaustion." -}} {{- end -}} Additionally, a comment in the `values.yaml` file should warn users about the performance implications of setting this value too high.
🟡 Warning	`components/tyk-gateway/templates/deployment-gw-repset.yaml:236`	The fallback `default` value for `TYK_GW_STORAGE_MAXIDLE` in the template is set to `100`, which is inconsistent with the previous hardcoded value of `1000`. If the `.Values.global.redis.maxIdle` value is not provided, this will cause the number of idle connections to drop significantly, potentially leading to performance degradation and impacting service availability in high-traffic environments. 💡 Suggestion To ensure consistent behavior and avoid potential performance regressions, the fallback default in the template should match the previous hardcoded value and the default specified in `values.yaml`. 🔧 Suggested Fix `value: "{{ default "1000" .Values.global.redis.maxIdle }}"`

Performance Issues (2)

Severity	Location	Issue
🟡 Warning	`components/tyk-gateway/templates/deployment-gw-repset.yaml:236`	The `default` value for `TYK_GW_STORAGE_MAXIDLE` in the template is set to `100`, which is inconsistent with the previous hardcoded value of `1000` and the new default of `1000` defined in `values.yaml`. If the `.Values.global.redis.maxIdle` value is not available for any reason, this will cause the number of idle connections to drop significantly, potentially leading to performance degradation in high-traffic environments due to increased latency when establishing new Redis connections. 💡 Suggestion To ensure consistent behavior and avoid potential performance regressions, the fallback default in the template should match the previous hardcoded value and the default specified in `values.yaml`. 🔧 Suggested Fix `value: "{{ default "1000" .Values.global.redis.maxIdle }}"`
🟡 Warning	`components/tyk-gateway/values.yaml:131`	The newly introduced `global.redis.maxIdle` parameter lacks validation to prevent excessively high values. A user misconfiguration could lead to resource exhaustion on the Tyk Gateway or the Redis server by maintaining a large number of idle connections, potentially causing performance degradation or a Denial of Service. 💡 Suggestion It is recommended to add validation for this input. While Helm's validation capabilities are limited, you could use the `fail` function within the template to enforce a sensible upper limit. For example, adding this to `deployment-gw-repset.yaml`: {{- if gt (int .Values.global.redis.maxIdle) 5000 -}} {{- fail "Error: global.redis.maxIdle must not exceed 5000 to prevent resource exhaustion." -}} {{- end -}} Additionally, a comment in the `values.yaml` file should warn users about the performance implications of setting this value too high.

Quality Issues (1)

Severity	Location	Issue
🟠 Error	`components/tyk-gateway/templates/deployment-gw-repset.yaml:236`	The Helm template's fallback default value for `TYK_GW_STORAGE_MAXIDLE` is `100`, which is inconsistent with both the previous hardcoded value (`1000`) and the new default value of `1000` specified in all `values.yaml` files. This discrepancy can lead to unexpected behavior and performance regressions for users who upgrade without explicitly defining `global.redis.maxIdle`, violating the principle of least surprise and making the chart's behavior difficult to reason about. 💡 Suggestion To ensure predictable behavior, maintain backward compatibility, and improve maintainability, the fallback default in the template must be aligned with the documented default in `values.yaml`. This consistency is crucial for reliable deployments. 🔧 Suggested Fix `value: "{{ default "1000" .Values.global.redis.maxIdle }}"`

Style Issues (6)

Severity	Location	Issue
🟢 Info	`components/tyk-gateway/values.yaml:130-132`	The new configuration block for `maxIdle` includes an extra blank line and uses a comment style that is inconsistent with the surrounding parameters, which follow a `# -- description` format. 💡 Suggestion To maintain consistent formatting, remove the blank line and update the comment to follow the established `# --` convention. 🔧 Suggested Fix `# -- Set the number of maximum idle connections in the Redis connection pool. maxIdle: 1000`
🟢 Info	`tyk-control-plane/values.yaml:179-181`	The new configuration block for `maxIdle` includes an extra blank line and uses a comment style that is inconsistent with the surrounding parameters. 💡 Suggestion To maintain consistent formatting, remove the blank line and update the comment to follow the established style in the file. 🔧 Suggested Fix `# Set the number of maximum idle connections in the Redis connection pool. maxIdle: 1000`
🟢 Info	`tyk-data-plane/values.yaml:159-161`	The new configuration block for `maxIdle` includes an extra blank line and uses a comment style that is inconsistent with the surrounding parameters. 💡 Suggestion To maintain consistent formatting, remove the blank line and update the comment to follow the established style in the file. 🔧 Suggested Fix `# Set the number of maximum idle connections in the Redis connection pool. maxIdle: 1000`
🟢 Info	`tyk-oss/values.yaml:142-144`	The new configuration block for `maxIdle` includes an extra blank line and uses a comment style that is inconsistent with the surrounding parameters. 💡 Suggestion To maintain consistent formatting, remove the blank line and update the comment to follow the established style in the file. 🔧 Suggested Fix `# Set the number of maximum idle connections in the Redis connection pool. maxIdle: 1000`
🟢 Info	`tyk-stack/values.yaml:180-182`	The new configuration block for `maxIdle` includes an extra blank line and uses a comment style that is inconsistent with the surrounding parameters. 💡 Suggestion To maintain consistent formatting, remove the blank line and update the comment to follow the established style in the file. 🔧 Suggested Fix `# Set the number of maximum idle connections in the Redis connection pool. maxIdle: 1000`
🟡 Warning	`components/tyk-gateway/templates/deployment-gw-repset.yaml:236`	The default value for `maxIdle` in the Helm template is `100`, which is inconsistent with the `1000` set in `values.yaml` and the previous hardcoded value. This discrepancy could cause unexpected performance degradation if the value is not explicitly set. 💡 Suggestion Align the template's default value with the one specified in the `values.yaml` files to ensure consistent behavior. 🔧 Suggested Fix `value: "{{ default \"1000\" .Values.global.redis.maxIdle }}"`

Powered by Visor from Probelabs

Last updated: 2025-10-03T13:56:00.670Z | Triggered by: synchronize | Commit: 59ed8aa

github-actions · 2025-12-17T17:56:24Z

🚨 Jira Linter Failed

Commit: 8879087
Failed at: 2025-12-17 17:56:23 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details

failed to validate branch and PR title rules: branch name 'tt-14402-support-for-storage-maxidle-gw-config' must contain a valid Jira ticket ID (e.g., ABC-123)

Next Steps

Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
Verify your PR title matches the branch's Jira ticket ID
Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

probelabs · 2025-12-17T17:56:48Z

This PR introduces a new Helm value, global.redis.maxIdle, to allow configuration of the TYK_GW_STORAGE_MAXIDLE environment variable for the Tyk Gateway. This enables users to tune the maximum number of idle connections in the Redis connection pool, a value that was previously hardcoded.

Files Changed Analysis

The changes are consistently applied across 6 files. The core logic change is in components/tyk-gateway/templates/deployment-gw-repset.yaml, where the hardcoded environment variable is replaced with a templated value. The other five changes introduce the new global.redis.maxIdle parameter (with a default of 1000) into the values.yaml files for tyk-gateway, tyk-control-plane, tyk-data-plane, tyk-oss, and tyk-stack.

A key observation is an inconsistency in the default values: the fallback default in the deployment template is 100, while the default in values.yaml and the previous hardcoded value was 1000. This could lead to unexpected performance changes on upgrade if the value is not explicitly set.

Architecture & Impact Assessment

What this PR accomplishes: It exposes the TYK_GW_STORAGE_MAXIDLE setting, giving users control over the gateway's Redis connection pool to optimize performance and resource usage.
Key technical changes introduced:
1. A new Helm parameter, global.redis.maxIdle, is added to all relevant values.yaml files.
2. The Tyk Gateway deployment template is updated to use this new parameter to set the corresponding environment variable.
Affected system components: The runtime configuration of the Tyk Gateway is the primary component affected. This impacts any deployment managed by these Helm charts.

Configuration Flow Diagram:

graph TD
    A["values.yaml<br/>(global.redis.maxIdle)"] --> B{Helm Template Engine};
    B --> C["deployment-gw-repset.yaml"];
    C --> D["Kubernetes Deployment Manifest"];
    D --> E["Gateway Pod with<br/>TYK_GW_STORAGE_MAXIDLE env var"];
    E --> F["Tyk Gateway Process"];

Scope Discovery & Context Expansion

The scope of this change is limited to the Helm chart configuration layer. It does not modify any application code within the Tyk Gateway itself but alters how it is configured upon deployment.
The change has been correctly propagated to all top-level charts that include the Tyk Gateway, ensuring a consistent configuration interface for users.
The most critical context for a reviewer is the discrepancy between the template's fallback default (100) and the values.yaml default (1000). This could be an unintentional breaking change for users who do not explicitly set the new value.

Metadata

Review Effort: 1 / 5
Primary Label: enhancement

Powered by Visor from Probelabs

Last updated: 2025-12-17T17:57:50.414Z | Triggered by: pr_updated | Commit: 8879087

💡 TIP: You can chat with Visor using /visor ask <your question>

probelabs · 2025-12-17T17:57:16Z

Security Issues (1)

Severity	Location	Issue
🟡 Warning	`components/tyk-gateway/values.yaml:131`	The new `global.redis.maxIdle` parameter lacks input validation, creating a risk of Denial of Service (DoS). A non-numeric value will cause the gateway to crash on startup. A very large numeric value could exhaust resources on the gateway and Redis server. This parameter is configured in multiple `values.yaml` files and used in `components/tyk-gateway/templates/deployment-gw-repset.yaml`. 💡 Suggestion 1. In `components/tyk-gateway/templates/deployment-gw-repset.yaml`, validate that `.Values.global.redis.maxIdle` is an integer using Helm's `kindIs` function. If validation fails, stop the release using the `fail` function. 2. In all `values.yaml` files where `maxIdle` is defined, add a comment warning users against setting an excessively high value to prevent resource exhaustion.

Architecture Issues (1)

Severity	Location	Issue
🟠 Error	`components/tyk-gateway/templates/deployment-gw-repset.yaml:240`	The default value for `TYK_GW_STORAGE_MAXIDLE` in the template is `100`, but the previous hardcoded value was `1000`. This is a potential breaking change for users who upgrade without setting `global.redis.maxIdle` in their values file, as it would reduce the max idle connections by a factor of 10. The default in the template should match the previous value to ensure backward compatibility. 💡 Suggestion To ensure backward compatibility for users upgrading the chart, the default value in the template should be changed from `100` to `1000` to match the previous hardcoded value. 🔧 Suggested Fix `value: "{{ default \"1000\" .Values.global.redis.maxIdle }}"`

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	`components/tyk-gateway/templates/deployment-gw-repset.yaml:240`	The fallback default for `TYK_GW_STORAGE_MAXIDLE` is set to `100` in the template, which is a 10x reduction from the previous hardcoded value of `1000` and the new default value in `values.yaml`. If a user overrides values and omits `global.redis.maxIdle`, the idle connection pool size will be silently reduced, potentially causing performance degradation (e.g., increased latency) in high-traffic environments. 💡 Suggestion To maintain backward compatibility and avoid unexpected performance changes, the fallback default in the template should be consistent with the previous value. Change `default "100"` to `default "1000"`.

Quality Issues (1)

Severity	Location	Issue
🟡 Warning	`components/tyk-gateway/templates/deployment-gw-repset.yaml:240`	The fallback default value for `TYK_GW_STORAGE_MAXIDLE` is `100`, which is inconsistent with the previous hardcoded value of `1000` and the new default of `1000` in `values.yaml`. This could lead to an unexpected and potentially detrimental configuration change for users if `.Values.global.redis.maxIdle` is not resolved during an upgrade. 💡 Suggestion To ensure backward compatibility and consistent behavior, the fallback default value in the template should match the previous hardcoded value. Please change `"100"` to `"1000"` inside the `default` function.

Powered by Visor from Probelabs

Last updated: 2025-12-17T17:57:53.149Z | Triggered by: pr_updated | Commit: 8879087

💡 TIP: You can chat with Visor using /visor ask <your question>

lghiur

LGTM

added handler for gateway storage maxidle config

d208f22

LLe27 requested a review from a team as a code owner October 3, 2025 13:27

LLe27 requested review from bsten-tyk and removed request for a team October 3, 2025 13:27

Long Le and others added 2 commits October 3, 2025 09:51

fix linter issues

59ed8aa

Merge branch 'main' into tt-14402-support-for-storage-maxidle-gw-config

8879087

lghiur approved these changes Dec 18, 2025

View reviewed changes

ilijabojanovic merged commit 0169bd4 into main Dec 18, 2025
7 of 15 checks passed

ilijabojanovic deleted the tt-14402-support-for-storage-maxidle-gw-config branch December 18, 2025 12:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[TT-14402] Add Handler for Gateway Storage MaxIdle Config #429

[TT-14402] Add Handler for Gateway Storage MaxIdle Config #429

Uh oh!

LLe27 commented Oct 3, 2025

Uh oh!

probelabs bot commented Oct 3, 2025 •

edited by atlassian bot

Loading

Uh oh!

probelabs bot commented Oct 3, 2025 •

edited

Loading

Uh oh!

github-actions bot commented Dec 17, 2025

Uh oh!

probelabs bot commented Dec 17, 2025 •

edited

Loading

Uh oh!

probelabs bot commented Dec 17, 2025 •

edited

Loading

Uh oh!

lghiur left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

[TT-14402] Add Handler for Gateway Storage MaxIdle Config #429

[TT-14402] Add Handler for Gateway Storage MaxIdle Config #429

Uh oh!

Conversation

LLe27 commented Oct 3, 2025

Description

Related Issue

Motivation and Context

Test Coverage For This Change

Screenshots (if appropriate)

Types of changes

Checklist

Uh oh!

probelabs bot commented Oct 3, 2025 • edited by atlassian bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔍 Code Analysis Results

Pull Request Analysis: TT-14402 Add Handler for Gateway Storage MaxIdle Config

1. Change Impact Analysis

What this PR Accomplishes

Key Technical Changes Introduced

Affected System Components

2. Architecture Visualization

Uh oh!

probelabs bot commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔍 Code Analysis Results

Security Issues (2)

Performance Issues (2)

Quality Issues (1)

Style Issues (6)

Uh oh!

github-actions bot commented Dec 17, 2025

🚨 Jira Linter Failed

Next Steps

Uh oh!

probelabs bot commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Files Changed Analysis

Architecture & Impact Assessment

Scope Discovery & Context Expansion

Uh oh!

probelabs bot commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Security Issues (1)

Architecture Issues (1)

Performance Issues (1)

Quality Issues (1)

Uh oh!

lghiur left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

probelabs bot commented Oct 3, 2025 •

edited by atlassian bot

Loading

probelabs bot commented Oct 3, 2025 •

edited

Loading

probelabs bot commented Dec 17, 2025 •

edited

Loading

probelabs bot commented Dec 17, 2025 •

edited

Loading