Redis sliding window disagrees with the in-memory one at window edges

This bug only manifests once you actually run the Redis backend -- i.e. the real, multi-instance production deployment shape, not local single-instance testing against the in-memory implementation. That's exactly the deployment most likely to matter most. With this live, a rule like free-tier (sold as "10 requests/minute") silently permits roughly double that at every window boundary, undermining the pricing/quota differentiation between tiers and removing the load-shedding protection any downstream system was sized around. It's also the kind of regression that passes every existing test (none of which exercise the Redis backend's edge timing) and would first be noticed in production, possibly during exactly the traffic spike the limiter exists to contain.

SlidingWindowMemory (Go) and SlidingWindowRedis (Lua, EVAL'd in Redis) are supposed to implement the identical algorithm -- that's the entire premise of "swapping backends never touches a call site" from the README. They no longer agree: right at a window boundary, the Redis-backed implementation computes the opposite of the intended weight for the previous window's contribution, which lets a full burst through that the in-memory implementation would correctly deny.

Create a SlidingWindowRedis (via a redis.Scripter, e.g. miniredis) with limit=5, window=2s. Fully consume the limit (5 requests) right as a window starts. Wait for the next window boundary (early into the following window -- elapsed_in_current is small). Make one more request for the same key. // got: allowed -- the buggy weight formula discards the previous window's count entirely at the boundary // want: denied -- the previous window (just filled to 5) is still almost entirely "in view" this early // into the new window, so 5+1 should exceed the limit of 5

This is exactly the burst-at-the-boundary problem that the two-window blending technique exists to prevent (a naive fixed-window counter has this exact flaw, which is the whole reason this smarter algorithm exists). With this bug, the Redis-backed free-tier rule effectively degrades into "reset fully every window boundary," i.e. a client can get roughly 2x their configured limit for free by timing requests around window edges, and the in-memory and Redis backends of the same rule would enforce visibly different effective limits.

Compare the weight expression line-by-line against sliding_window.go's Go implementation of the same formula -- they should be structurally identical modulo Lua vs. Go syntax. Everything else in the Lua script (window rollover, HMSET/EXPIRE, the remaining calculation) is correct and should not need to change.