Tyk Gateway 5.4 Release Notes

Last updated: 11 minutes read.

Open Source (Mozilla Public License)

This page contains all release notes for version 5.4.X displayed in a reverse chronological order

Support Lifetime

Our minor releases are supported until our next minor comes out.

5.4.0 Release Notes

Release Date 2 July 2024

Breaking Changes

Attention: Please read this section carefully

We have fixed a bug in the way that Tyk calculates the key-level rate limit when multiple policies are applied to the same key. This fix alters the logic used to calculate the effective rate limit and so may lead to a different rate limit being applied to keys generated from your existing policies. See the change log for details of the change.

Dependencies

Compatibility Matrix For Tyk Components

Gateway Version Recommended Releases Backwards Compatibility
5.4.0 MDCB v2.6 MDCB v2.4.2
Operator v0.18 Operator v0.17
Sync v1.5 Sync v1.4.3
Helm Chart v1.5.0 Helm all versions
EDP v1.9 EDP all versions
Pump v1.10.0 Pump all versions
TIB (if using standalone) v1.5.1 TIB all versions

The above table needs reviewing and updating if necessary

3rd Party Dependencies & Tools

Third Party Dependency Tested Versions Compatible Versions Comments
Go 1.19 (GQL), 1.21 (GW) 1.19 (GQL), 1.21 (GW) Go plugins must be built using Go 1.21
Redis 6.2.x, 7.x 6.2.x, 7.x Used by Tyk Gateway
OpenAPI Specification v3.0.x v3.0.x Supported by Tyk OAS

Given the potential time difference between your upgrade and the release of this version, we recommend users verify the ongoing support of third-party dependencies they install, as their status may have changed since the release.

The above table needs reviewing and updating if necessary

Deprecations

There are no deprecations in this release.

Upgrade instructions

If you are upgrading to 5.4.0, please follow the detailed upgrade instructions.

Add upgrade steps here if necessary.

Release Highlights

We’re thrilled to introduce exciting enhancements in Tyk Gateway 5.4, aimed at improving your experience with Tyk Gateway. For a comprehensive list of changes, please refer to the change log below.

Enhanced Rate Limiting Strategies

We’ve introducing a Rate Limit Smoothing option for the spike arresting Redis Rate Limiter to give the upstream time to scale in response to increased request rates.

Fixed MDCB Issue Relating To Replication Of Custom Keys To Dataplanes

Resolved an issue encountered in MDCB environments where changes to custom keys made via the Dashboard were not properly replicated to dataplanes. The issue impacted both key data and associated quotas, in the following versions:

  • 5.0.4 to 5.0.12
  • 5.1.1 and 5.1.2
  • 5.2.0 to 5.2.6
  • 5.3.0 to 5.3.2
Action Required

Customers should clear their edge Redis instances of any potentially affected keys to maintain data consistency and ensure proper synchronization across their environments. Please refer to the item in the fixed section of the changelog for recommended actions.

Fixed Window Rate Limiter

Ideal for persistent connections with load-balanced gateways, the Fixed Window Rate Limiter algorithm mechanism ensures fair handling of requests by allowing only a predefined number to pass per rate limit window. It uses a simple shared counter in Redis so requests do not need to be evenly balanced across the gateways.

Event handling with Tyk OAS

We’ve added support for you to register webhooks with your Tyk OAS APIs so that you can handle events triggered by the Gateway, including circuit breaker and quota expiry. You can also assign webhooks to be fired when using the new smoothing rate limiter to notify your systems of ongoing traffic spikes.

Enhanced Header Handling in GraphQL APIs

Introduced a features object in API definitions for GQL APIs, including the use_immutable_headers attribute. This allows advanced header control, enabling users to add new headers, rewrite existing ones, and selectively remove specific headers. Existing APIs will have this attribute set to false by default, ensuring no change in behavior. For new APIs, this attribute is true by default, facilitating smoother migration and maintaining backward compatibility.

Downloads

Changelog

Added

  • Implemented Fixed Window Rate Limiting for load balancers with keep-alives

    Introduced a Fixed Window Rate Limiting mechanism to handle rate limiting for load balancers with keep-alives. This algorithm allows the defined number of requests to pass for every rate limit window and blocks any excess requests. It uses a simple shared counter in Redis to count requests. It is suitable for situations where traffic towards Gateways is not balanced fairly. To enable this rate limiter, set enable_fixed_window_rate_limiter in the gateway config or set the environment variable TYK_GW_ENABLEFIXEDWINDOWRATELIMITER=true.

  • Introduced Rate Limit Smoothing for scaling

    Implemented Rate Limit Smoothing as an extension to the existing Redis Rate Limiter to gradually adjust the rate based on smoothing configuration. Two new Gateway events have been created (RateLimitSmoothingUp and RateLimitSmoothingDown) which will be triggered as smoothing occurs. These can be used to assist with auto-scaling of upstream capacity during traffic spikes.

  • Introduced ‘use_immutable_headers’ for Advanced Header Control in GraphQL APIs

    We’ve added the use_immutable_headers option to the GraphQL API configuration, offering advanced header transformation capabilities. When enabled, users can add new headers, rewrite existing ones, and selectively remove specific headers, allowing granular control without altering the original request. Existing APIs will default to false, maintaining current behavior until ready for upgrade.

  • Enhanced manual schema addition for GQL APIs

    Introduced an option for users to manually provide GQL schemas when creating APIs in Tyk, eliminating the dependency on upstream introspection. This feature enables the creation and editing of GQL APIs in Tyk even when upstream introspection is unavailable, providing flexibility for schema management as upstream configurations evolve over time.

  • Introduced Tyk v3 GraphQL Engine in Gateway

    The new GraphQL engine, version 3-preview, is now available in Tyk Gateway. It can be used for any GQL API by using the following enum in raw API definition: “version”: “3-preview”. This experimental version offers optimized GQL operation resolution, faster response times, and a more efficient data loader. It is currently not recommended for production use and will be stabilised in future releases, eventually becoming the default for new GQL APIs in Tyk.

  • Introduced features Object in API Definition for GQL APIs

    Enhanced request headers handling in API definitions for GQL APIs by introducing a features object. Users can now set the use_immutable_headers attribute, which defaults to false for existing APIs, ensuring no change in header behavior. For new APIs, this attribute is true by default, facilitating smoother migration and maintaining backwards compatibility.

  • New Tyk OAS features

    We’ve added some more features to the Tyk OAS API, moving closer to full parity with Tyk Classic. In this release we’ve added controls that allow you: to enable or prevent generation of traffic logs at the API-level and to enable or prevent the availability of session context to middleware. We’ve also added the facility to register webhooks that will be fired in response to Gateway events.

Fixed

  • Resolved an issue where changes to custom keys were not properly replicated to dataplanes

    Resolved a critical issue affecting MDCB environments, where changes to custom keys made via the dashboard were not properly replicated to dataplanes. This affected both the key data and associated quotas. This issue was present in versions:

    • 5.0.4 to 5.0.12
    • 5.1.1 and 5.1.2
    • 5.2.0 to 5.2.6
    • 5.3.0 to 5.3.2

    Action Required

    Customers are advised to clear their edge Redis instances of any keys that might have been affected by this bug to ensure data consistency and proper synchronization across their environments. There are several methods available to address this issue:

    1. Specific Key Deletion via API: To remove individual buggy keys, you can use the following API call:
    curl --location --request DELETE 'http://tyk-gateway:{tyk-hybrid-port}/tyk/keys/my-custom-key' \ --header 'X-Tyk-Authorization: {dashboard-key}'

    Replace {tyk-hybrid-port}, my-custom-key and {dashboard-key} with your specific configuration details. This method is safe and recommended for targeted removals without affecting other keys.

    1. Bulk Key Deletion Using Redis CLI: For environments with numerous affected keys, you might consider using the Redis CLI to remove keys en masse:
    redis-cli --scan --pattern 'apikey-*' | xargs -L 1 redis-cli del
redis-cli --scan --pattern 'quota-*' | xargs -L 1 redis-cli del

    This method can temporarily impact the performance of the Redis server, so it should be executed during a maintenance window or when the impact on production traffic is minimal.

    1. Complete Redis Database Flush: If feasible, flushing the entire Redis database offers a clean slate:
    redis-cli FLUSHALL ASYNC

    Implications Regardless of the chosen method, be aware that quotas will be reset and will need to resynchronize across the system. This may temporarily affect reporting and rate limiting capabilities.

  • Resolved service discovery issue when using Consul

    Addressed an issue with service discovery where an IP returned by Consul wasn’t parsed correctly on the Gateway side, leading to unexpected errors when proxying requests to the service. Typically, service discovery returns valid domain names, which did not trigger the issue.

  • Corrected naming for semantic conventions attributes in GQL Spans

    Fixed an issue where GQL Open Telemetry semantic conventions attribute names that lacked the ‘graphql’ prefix, deviating from the community standard. All attributes now have the correct prefix.

  • Fixed missing GraphQL OTel attributes in spans on request validation failure

    Corrected an issue where GraphQL OTel attributes were missing from spans when request validation failed in cases where detailed_tracing was set to false. Traces now include GraphQL attributes (operation name, type, and document), improving debugging for users.

  • Resolved Gateway panic with Persist GraphQL Middleware

    Fixed a gateway panic issue observed by users when using the Persist GQL middleware without defined arguments. The gateway will no longer throw panics in these cases.

  • Resolved issue with GraphQL APIs handling OPTIONS requests

    Fixed an issue with GraphQL API’s Cross-Origin Resource Sharing (CORS) configuration, which previously caused the API to fail in respecting CORS settings. This resulted in an inability to proxy requests to upstream servers and handle OPTIONS/CORS requests correctly. With this fix, users can now seamlessly make requests, including OPTIONS method requests, without encountering the previously reported error.

  • Resolved conflict with multiple APIs sharing listen path on different domains

    Fixed an issue where the Gateway did not respect API domain settings when there was another API with the same listen path but no domain. This could lead to the custom domain API not functioning correctly, depending on the order in which APIs were loaded. APIs with custom domains are now prioritised before those without custom domains to ensure that the custom domain is not ignored.

  • Resolved nested field mapping issue in Universal Data Graph

    Addressed a problem with nested field mapping in UDG for GraphQL (GQL) operations. Previously, querying a single nested field caused an error, while including another normal field from the same level allowed the query to succeed. This issue has been fixed to ensure consistent behavior regardless of the query composition.

  • Fixed an error in the calculation of effective rate limit from multiple policies

    Fixed a long-standing bug in the algorithm used to determine the effective rate limit when multiple policies are applied to a key. If more than one policy is applied to a key then Tyk will apply the highest request rate permitted by any of the policies that defines a rate limit.

    Rate limits in Tyk are defined using two elements: rate, which is the number of requests and per, which is the period over which those requests can be sent. So, if rate is 90 and per is 30 seconds for a key, Tyk will permit a maximum of 90 requests to be made using the key in a 30 second period, giving an effective maximum of 180 requests per minute (or 3 rps).

    Previously, Tyk would take the highest rate and the highest per from the policies applied to a key when determining the effective rate limit. So, if policy A had rate set to 90 and per set to 30 seconds (3rps) while policy B had rate set to 100 and per set to 10 seconds (10rps) and both were applied to a key, the rate limit configured in the key would be: rate = 100 and per = 30 giving a rate of 3.33rps.

    With the fix applied in Tyk 5.4.0, the Gateway will now apply the highest effective rate to the key - so in this example, the key would take the rate limit from policy B: rate = 100 and per = 10 (10rps).

    Note that this corrected logic is applied when access keys are presented in API requests. If you are applying multiple policies to keys, there may be a change in the effective rate limit when using Tyk 5.4.0 compared with pre-5.4.0 versions.

Security Fixes

  • High priority CVEs fixed

    Fixed the following high priority CVEs identified in the Tyk Gateway, providing increased protection against security vulnerabilities:

Further Information

Upgrading Tyk

Please refer to the upgrading Tyk page for further guidance on the upgrade strategy.

API Documentation

FAQ

Please visit our Developer Support page for further information relating to reporting bugs, upgrading Tyk, technical support and how to contribute.

See also

Return to Top
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.
   Read More