1. update limit-req doc for the parameter
2. add the corresponding zh docs

done

The TTL for limit-req is hardcoded to 2 seconds. This feels arbitrary and lacks flexibility.

The ttl_policy_schema function modifies a shared table, is this safe?

No it is not. Good catch. Let me fix this.

Need to add a scenario where a key's TTL expires. The test should verify that the counter is effectively gone and that a new request can proceed without being blocked by a stale counter.

•Example: Set a short TTL (e.g., 2s), make a request, wait for 3s, and then confirm that a subsequent request does not inherit the old counter value.

done

The comment indicates that the TTL calculation formula is ceil(burst/rate) + 1, which would equal 11 seconds for rate=1 and burst=10. However, this formula and comment appear to be copied from limit-req tests but are actually checking a hardcoded 2-second TTL in the implementation. This comment is misleading and should be updated to reflect the actual TTL value of 2 seconds that is set in the implementation.

This function mutates the original schema object from policy_to_additional_properties by directly adding the key_ttl property. This means that after the first call, the schema will be modified permanently for all subsequent uses. This could lead to unexpected behavior if the schema is reused elsewhere.

Consider creating a deep copy of the schema before adding the key_ttl property to avoid mutating the shared schema object.

The limit-req plugin uses a hardcoded TTL of 2 seconds for Redis keys, while the limit-conn plugin has a configurable key_ttl parameter with a default of 60 seconds. This inconsistency means:

1. Users cannot configure the TTL for limit-req Redis keys
2. The 2-second TTL may be too short for high-burst scenarios where requests are queued

Consider making the TTL configurable for limit-req as well, similar to limit-conn. The TTL could be calculated as ceil(burst/rate) + a safety margin to ensure keys persist long enough for delayed requests to be processed.

The test expects a TTL of up to 11 seconds (based on the formula ceil(burst/rate) + 1 = ceil(10/1) + 1 = 11), but the implementation in apisix/plugins/limit-req/util.lua sets a hardcoded TTL of 2 seconds. This test will pass since 2 is within the range (0, 11], but the test is validating against the wrong expected value.

The test should check for TTL <= 2 to match the actual implementation, or the implementation should be updated to use a calculated TTL based on burst and rate parameters.

Similar to the redis test, this test expects a TTL of up to 11 seconds based on the formula ceil(burst/rate) + 1, but the implementation uses a hardcoded 2-second TTL. The test should check for TTL <= 2 to match the actual implementation, or the implementation should use a calculated TTL.

I think the default value can be 3600, means 1hour

it should be enough

makes sense, I have set the default ttl to be 3600.

you can take a look at this example, which is better performance

we can cache the sha1 of Lua script, then we call evalsha

local redis = require "resty.redis"
local red = redis:new()

-- 1. Define your fixed script and pre-calculate its SHA1 locally
-- You can use an online SHA1 tool or calculate it via code
local script_content = "return redis.call('GET', KEYS[1])"
local script_sha1 = "6bce267422d7793d3e0034d7c99602029c5737e6"

red:set_timeout(1000) -- 1 sec
local ok, err = red:connect("127.0.0.1", 6379)
if not ok then
    ngx.log(ngx.ERR, "failed to connect: ", err)
    return
end

--- Function to execute script with EVALSHA optimization
local function optimized_eval(red, sha1, script, num_keys, ...)
    -- Try EVALSHA first
    local res, err = red:evalsha(sha1, num_keys, ...)
    
    -- If the script is missing in Redis (NOSCRIPT error)
    if not res and err and string.find(err, "NOSCRIPT") then
        ngx.log(ngx.INFO, "Script not found in cache, loading now...")
        
        -- Load the script to get the SHA1 (or verify it)
        local new_sha, load_err = red:script("LOAD", script)
        if not new_sha then
            return nil, "failed to load script: " .. (load_err or "")
        end
        
        -- Retry EVALSHA with the loaded script
        return red:evalsha(new_sha, num_keys, ...)
    end
    
    return res, err
end

-- 2. Call the function
local res, err = optimized_eval(red, script_sha1, script_content, 1, "my_key")

if not res then
    ngx.say("Error: ", err)
else
    ngx.say("Result: ", res)
end

-- Put it back in the connection pool
red:set_keepalive(10000, 100)

done

another example, gen the sha1 by redis:script:

local function fetch_latest_redis_script_sha1()
    if redis_incoming_script_sha then
        return redis_incoming_script_sha
    end
    
    local sha1, load_err = red:script("LOAD", lua_script)
    if load_err then
        return nil, load_err
    end

    redis_incoming_script_sha = sha1
    return redis_incoming_script_sha
end

local sha1, err = fetch_latest_redis_script_sha1()
if not sha1 then
    ngx.log(ngx.ERR, "Failed to load Lua script into Redis: ", err)
    return nil, err
end

local res, err = red:evalsha(sha1, ...)
if err and core.string.has_prefix(err, "NOSCRIPT") then
    redis_incoming_script_sha = nil
end

it is more safer than we generate it by ngx api

got it, I have fixed this too now.

FYI, lua-resty-redis-cluster didn't work with evalsha so I ensured a conditional usage of plain redis eval by rediscluster policy and evalsha usage by redis policy.