[Bug]: Redis-backed rate limit policies ignore integer values from config.toml and fall back to schema defaults

Please select the area the issue is related to

Gateway

Please select the aspect the issue is related to

Aspect/API (API backends, definitions, contracts, interfaces, OpenAPI)

Description

Whole numbers configured under [policy_configurations.*] decode as int64, and the CEL-based ${config...} resolution also returns integers as int64, but getIntParam in the shared advanced-ratelimit engine only accepts float64 and int, so the value is silently discarded and the schema default is used, with nothing logged.

Since basic-ratelimit, advanced-ratelimit, token-based-ratelimit, llm-cost-based-ratelimit and mcp-ratelimit all delegate to that engine, all five are affected for redis.port, redis.db, redis.poolSize and the local.* limits. Most visibly redis.port, which reverts to 6379 so any Redis on a non-default port fails with a dial timeout and rate limiting silently stops being enforced. Writing the value as a decimal (port = 13118.0) makes it resolve as float64 and work, confirming the value is rejected on type rather than being missing or misnamed.

Steps to Reproduce

Steps to reproduce

• Provision a Redis instance on a non-default port (e.g. Redis Cloud on 13118).
• Add to configs/config.toml:

[policy_configurations.ratelimit_v1]
algorithm = "fixed-window"
backend = "redis"

[policy_configurations.ratelimit_v1.redis]
host = "<redis-host>"
port = 13118
username = "default"
password = "<password>"
failure_mode = "open"

• Attach basic-ratelimit (limit 2 / 1m) to an LLMProvider API resource from the AI Workspace UI and deploy.
• Restart the gateway: docker compose restart gateway-runtime.
• Send a request through the API.

Actual

redis: connection pool: failed to dial after 1 attempts: dial tcp :6379: i/o timeout
WARN Rate limit check failed (fail-open) error="redis INCRBY failed: dial tcp :6379: i/o timeout" quota=default

Host resolved correctly, port silently replaced with the default 6379; no rate limiting occurs (fail-open).

Expected

Connects to :13118 and enforces the limit. If a config value can't be applied, it should be logged, not silently dropped.

Severity Level of the Issue

Severity/Major (Important functionality is broken. Should be prioritized. Doesn't need immediate attention)

Environment Details (with versions)

No response

Start at getIntParam in the shared advanced-ratelimit engine and trace how values from configs/config.toml and CEL-based ${config...} resolution are handled. Reproduce with an integer redis.port under policy_configurations and the basic-ratelimit path. Done means integer values work for the affected Redis and local.* settings, and rejected values are not silently discarded.