bug: 5h 限额用量统计不准确

[ding113]

部分场景下，发现用户的5h 限额用量统计不准确，甚至会超过用户的总用量。
通过使用日志页面筛选后发现，5h 限额统计有概率偏大。

[github-actions]

Thank you for reporting this issue.

Analysis:

Based on my investigation of the codebase, I've identified a potential root cause for the inaccurate 5h quota usage statistics.

The Core Issue: Cache Warming Logic

The 5h limit uses a rolling window mechanism with Redis ZSET (sorted set). When there's a Redis cache miss (key doesn't exist or returns 0), the system falls back to a database query and then "warms" the cache. The problem lies in how cache warming is implemented:

Affected code:

• src/lib/rate-limit/service.ts (lines 774-796) - getCurrentCost() method
• src/lib/rate-limit/service.ts (lines 368-387) - checkCostLimitsFromDatabase() method

Problem scenario:

1. When cache miss occurs, the code queries the database for the 5h cost total
2. It then warms the cache by writing this total as a single entry with the current timestamp:

// Line 786-793 in service.ts
await RateLimitService.redis.eval(
  TRACK_COST_5H_ROLLING_WINDOW,
  1,
  key,
  current.toString(),  // Total from DB becomes a single entry
  now.toString(),       // With current timestamp
  window5h.toString()
);

3. This creates an entry like "1734567890000:5.50" in the ZSET, representing the entire historical cost as if it happened at one moment

Why this causes over-counting:

• If the user makes new requests after cache warming, those costs are added as new entries
• The cache now contains: the warmed total + new individual costs
• When calculating the 5h cost, both are summed, resulting in double-counting

For example:

• DB shows 5h cost = $5.00 (from requests made 3h, 2h, 1h ago)
• Cache warming writes $5.00 at current time
• User makes a new $1.00 request
• Cache now has: $5.00 (warmed) + $1.00 (new) = $6.00
• But actual 5h usage is only $6.00 (correct) or could be $11.00 (if warmed entry is counted twice)

Additionally:

The same pattern exists in the Lua script TRACK_COST_5H_ROLLING_WINDOW (src/lib/redis/lua-scripts.ts, lines 120-148), which stores costs as timestamp:cost entries and sums them. When cache warming writes a cumulative total as a single entry, subsequent accurate tracking becomes problematic.

To help diagnose this further, please provide:

• Redis key inspection: Can you check the contents of a specific user's key:{keyId}:cost_5h_rolling ZSET when the issue occurs?
• Comparison of the database query result vs Redis ZSET sum for the same time window
• Whether the issue is more pronounced after Redis restart or cache expiration

Potential workaround:

Manually flushing the affected Redis keys (pattern: *:cost_5h_rolling) may temporarily reset the statistics to accurate values (they will be recalculated from the database on next cache miss).

---

Automated response from Claude AI