Skip to content

TT-6075: Update rate limit implementation #7941

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
vladzabolotnyi merged 76 commits into from
Apr 20, 2026

Merge branch 'master' into feat/TT-6075/update-rate-limit-header-logic

93571d1
Select commit
Loading
Failed to load commit list.
Merged

TT-6075: Update rate limit implementation #7941

Merge branch 'master' into feat/TT-6075/update-rate-limit-header-logic
93571d1
Select commit
Loading
Failed to load commit list.
probelabs / Visor: quality failed Apr 20, 2026 in 1m 18s

🚨 Check Failed

quality check failed because fail_if condition was met.

Details

📊 Summary

  • Total Issues: 4
  • Error Issues: 3
  • Warning Issues: 1

🔍 Failure Condition Results

Failed Conditions

  • global_fail_if: output.issues && output.issues.some(i => i.severity === 'critical' || i.severity === 'error')
    • Severity: ❌ error

Issues by Category

Logic (3)

  • ❌ gateway/session_manager.go:479 - The quota reset time, an int64 value from expiredAt.Unix(), is cast to int before being passed to extendContextWithQuota. On 32-bit systems, where int is 32 bits, this will cause an integer overflow for dates beyond January 2038 (the Y2038 problem). This results in incorrect quota reset times being stored in context variables, leading to faulty behavior in middleware that relies on this data.
  • ❌ gateway/session_manager.go:606 - The resetTime variable, which is an int64 returned by time.Now().Add(stats.Reset).Unix(), is cast to an int before being stored in the request context data. On 32-bit systems, this cast can lead to an integer overflow for dates beyond the year 2038, causing incorrect rate limit reset times to be exposed as context variables.
  • ❌ system:0 - Global failure condition met: output.issues && output.issues.some(i => i.severity === 'critical' || i.severity === 'error')

Style (1)

  • ⚠️ gateway/mw_api_rate_limit_test.go:19 - The test logic in TestAPIRateLimitResponseHeaders is nearly identical to the logic in TestRateLimitResponseHeaders in gateway/mw_rate_limiting_test.go. Both functions iterate through the same set of rate limiters and perform similar request and response header checks. The primary difference is that one tests keyless (global) rate limits while the other tests per-key rate limits. This duplication makes the tests harder to maintain, as any change to the testing logic must be applied in two places.

Powered by Visor from Probelabs

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

Annotations

Check failure on line 479 in gateway/session_manager.go

See this annotation in the file changed.

@probelabs probelabs / Visor: quality

logic Issue 

The quota reset time, an `int64` value from `expiredAt.Unix()`, is cast to `int` before being passed to `extendContextWithQuota`. On 32-bit systems, where `int` is 32 bits, this will cause an integer overflow for dates beyond January 2038 (the Y2038 problem). This results in incorrect quota reset times being stored in context variables, leading to faulty behavior in middleware that relies on this data.
Raw output 
Modify the `extendContextWithQuota` function to accept an `int64` for the reset time. Pass the value from `expiredAt.Unix()` without casting to prevent potential overflow on 32-bit architectures. The `valToStr` function, which consumes these context variables, already handles `int64`.

Check failure on line 606 in gateway/session_manager.go

See this annotation in the file changed.

@probelabs probelabs / Visor: quality

logic Issue 

The `resetTime` variable, which is an `int64` returned by `time.Now().Add(stats.Reset).Unix()`, is cast to an `int` before being stored in the request context data. On 32-bit systems, this cast can lead to an integer overflow for dates beyond the year 2038, causing incorrect rate limit reset times to be exposed as context variables.
Raw output 
Store the `resetTime` as an `int64` in the context map to ensure 64-bit precision and avoid the Y2038 problem on 32-bit platforms. The `valToStr` function used for processing context variables already supports `int64`, so this change should not require further modifications downstream.

Check warning on line 99 in gateway/mw_api_rate_limit_test.go

See this annotation in the file changed.

@probelabs probelabs / Visor: quality

style Issue 

The test logic in `TestAPIRateLimitResponseHeaders` is nearly identical to the logic in `TestRateLimitResponseHeaders` in `gateway/mw_rate_limiting_test.go`. Both functions iterate through the same set of rate limiters and perform similar request and response header checks. The primary difference is that one tests keyless (global) rate limits while the other tests per-key rate limits. This duplication makes the tests harder to maintain, as any change to the testing logic must be applied in two places.
Raw output 
Refactor the common test logic into a shared test helper function. This helper could accept parameters to configure the API for either keyless or per-key rate limiting and to determine whether an authorization header should be sent. This would eliminate significant code duplication and centralize the test logic, improving maintainability.
View more details on probelabs