Bug: Time precision loss in Lua scripts at high QPS

[tanbro]

Severity

High

Location

File: src/redis_func_cache/lua/lru_t_get.lua
Lines: 29-30

Description

The timestamp calculation uses floating-point arithmetic:

local time = redis.call('TIME')
local timestamp = time[1] + time[2] * 1e-6
redis.call('ZADD', zset_key, timestamp, hash)

The redis.call('TIME') returns seconds and microseconds separately, but converting to float and back loses microsecond precision due to floating-point representation limitations.

Impact

Under high QPS (>1000 req/s), multiple accesses may appear to have the same timestamp, breaking LRU ordering. This causes:

• Incorrect eviction decisions
• Cache effectiveness reduction
• Non-deterministic behavior under load

Reproduction Steps

Run benchmark with high QPS:

redis-benchmark -t set,get -n 100000 -q
# Monitor cache hit ratios and eviction patterns

Proposed Solution

Use integer arithmetic to preserve precision:

local time = redis.call('TIME')
local timestamp = time[1] * 1000000 + time[2]  -- microseconds as integer
redis.call('ZADD', zset_key, timestamp, hash)

Additional Context

• Affects all time-based policies (LruT*, FifoT*)
• Redis TIME command returns: [seconds, microseconds]
• JavaScript Number type has 53-bit precision limit
• Microseconds as integer fits in 64-bit integer