This PR introduces an API-level timeout configuration, creating a new layer of control between the global gateway-level default and specific endpoint-level timeouts. This feature allows developers to set a uniform timeout for all endpoints within an API definition, simplifying configuration and reducing redundancy. The new timeout precedence is: Endpoint-level → API-level → Gateway default.

Files Changed Analysis

The changes are primarily located in the apidef and gateway packages.

• apidef/: The core API definition (APIDefinition) is extended with GlobalEnforceTimeout and GlobalEnforceTimeoutDisabled fields in apidef/api_definitions.go. Corresponding updates are made to the classic JSON schema (apidef/schema.json), OpenAPI (OAS) schemas (apidef/oas/schema/, apidef/mcp/schema/), data migration logic (apidef/migration.go), and validation rules (apidef/validator.go). The OAS mapping logic in apidef/oas/upstream.go is updated to handle the new enforceTimeout object. Extensive unit tests are added to verify schema correctness, validation, and OAS round-tripping.
• gateway/: The request processing logic is updated. The gateway/reverse_proxy.go module now includes the API-level timeout in its timeout resolution logic by renaming GetHardTimeoutEnforcedSettings to GetEnforcedTimeoutSettings and updating its logic. The middleware in gateway/middleware.go is adjusted to activate timeout enforcement when an API-level timeout is present. A comprehensive integration test suite (TestAPILevelTimeout) is added in gateway/reverse_proxy_test.go to validate the new timeout hierarchy and behavior under various conditions.

Architecture & Impact Assessment

• What this PR accomplishes: It provides a more flexible and granular timeout configuration model. Users can now define a default timeout for an entire API, which is less tedious than configuring each endpoint individually, while still allowing for endpoint-specific overrides.

• Key technical changes introduced:

  1. New API Definition Fields: Adds global_enforce_timeout and global_enforce_timeout_disabled to the apidef.VersionInfo struct.
  2. OAS Extension: Introduces the x-tyk-api-gateway.upstream.enforceTimeout object in the OpenAPI specification for managing this setting.
  3. Updated Timeout Prioritization: The gateway's reverse proxy logic is modified to resolve timeouts in the order: Endpoint-level → API-level → Gateway default.

• Affected system components:

  • Gateway Proxy: The core request-handling path in gateway/reverse_proxy.go is directly modified to implement the new timeout hierarchy.
  • API Definition Handling: The apidef package is updated to handle the new fields during validation, migration, and OAS conversion.
  • External Tooling: Systems that interact with Tyk API definitions, such as the Tyk Dashboard, Management API, and Tyk Operator, will likely require updates to expose and manage these new configuration fields.

Timeout Resolution Flow

The diagram below illustrates how the gateway determines which timeout to apply to an incoming request.

graph TD
    A[Incoming Request] --> B{Check for Endpoint-Level Timeout};
    B --|Yes|--> C[Use Endpoint Timeout];
    B --|No|--> D{Check for API-Level Timeout};
    D --|"Yes (Enabled)"|--> E[Use API-Level Timeout];
    D --|"No / Disabled"|--> F[Use Gateway Default Timeout];
    C --> G[Apply Timeout and Proxy Request];
    E --> G;
    F --> G;

Scope Discovery & Context Expansion

• The scope of this PR is well-defined and contained within the Tyk gateway's codebase. The changes are implemented end-to-end, from the data definition layer (apidef) to the runtime enforcement logic (gateway).
• The central logic change resides in gateway/reverse_proxy.go within the GetEnforcedTimeoutSettings function. This function is called from WrappedServeHTTP for every request, placing it directly in the critical path of request processing.
• The modification in gateway/middleware.go is a necessary supporting change that ensures the EnforcedTimeoutEnabled flag is set on the API specification at load time if an API-level timeout is configured, which in turn ensures the timeout resolution logic is executed.
• The addition of extensive integration tests in gateway/reverse_proxy_test.go provides strong confidence that the timeout precedence (endpoint > API > gateway) and fallback mechanisms function correctly. No further code exploration seems necessary to understand the immediate impact.

Powered by Visor from Probelabs

Last updated: 2026-06-15T11:48:22.488Z | Triggered by: pr_updated | Commit: ed26897

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

Security Issues (1)

Security Issues (1)

No architecture issues found – changes LGTM.

✅ Performance Check Passed

No performance issues found – changes LGTM.

Quality Issues (1)

func TestSetDisabledFlags_GlobalEnforceTimeout(t *testing.T) {
	t.Run("when timeout is not configured, disabled flag is set", func(t *testing.T) {
		api := &apidef.APIDefinition{
			VersionData: apidef.VersionData{
				Versions: map[string]apidef.VersionInfo{
					"Default": {GlobalEnforceTimeout: 0},
				},
			},
		}
		api.SetDisabledFlags()
		assert.True(t, api.VersionData.Versions["Default"].GlobalEnforceTimeoutDisabled)
	})

	t.Run("when timeout is configured, disabled flag is not set", func(t *testing.T) {
		api := &apidef.APIDefinition{
			VersionData: apidef.VersionData{
				Versions: map[string]apidef.VersionInfo{
					"Default": {GlobalEnforceTimeout: tyktime.ReadableDuration(5 * time.Second)},
				},
			},
		}
		api.SetDisabledFlags()
		assert.False(t, api.VersionData.Versions["Default"].GlobalEnforceTimeoutDisabled)
	})
}

Powered by Visor from Probelabs

Last updated: 2026-06-15T11:47:43.537Z | Triggered by: pr_updated | Commit: ed26897

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

/visor

The API-level timeout validation only checks for negative values, but does not enforce an upper limit. An administrator could configure an excessively large timeout (e.g., hours or days), which could lead to resource exhaustion on the gateway by tying up connections for extended periods. This increases the risk of denial-of-service, especially since this setting can apply to all endpoints within an API.

This is intended behavior that described on the latest comments on the ticket

Powered by Visor from Probelabs

Last updated: 2026-06-05T07:35:43.627Z | Triggered by: vladzabolotnyi | Commit: 749796e

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

🎯 Recommended Merge Targets

Based on JIRA ticket TT-15813: [BE] Feature Request: API-Level Timeout Configuration

Fix Version: Tyk 5.14.0

⚠️ Warning: Expected release branches not found in repository

Required:

• master - No matching release branches found. Fix will be included in future releases.

📋 Workflow

1. Merge this PR to master first

SentinelOne CNS Hardcoded Secret Detector
✅ Congratulations, your code is safe

SentinelOne CNS is a cloud-agnostic, agentless CSPM & CWPP solution that continuously detects and prevents vulnerabilities that have the highest probability of being exploited in Azure, AWS, Google Cloud, and Kubernetes.

🚨 Jira Linter Failed

Commit: ed26897
Failed at: 2026-06-15 11:46:11 UTC

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

failed to get Jira issue: failed to fetch Jira issue TT-15813: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

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.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud