Every denied request panics the Redis-backed token bucket

This is arguably the most severe item on this list: it crashes on the routine, expected outcome of rate limiting, not a rare edge case. On the Redis backend (the real multi-instance production deployment), the moment any customer actually reaches their limit -- which is supposed to produce a clean, well-understood 429 -- the request panics instead. That means your best, busiest, most-engaged customers (the ones who hit limits) are exactly the ones who experience this as broken/crashing behavior, likely with noisy error logs or process instability on every occurrence, the opposite of the graceful "please slow down" experience a rate limiter is supposed to provide.

TokenBucketRedis.AllowN panics instead of returning Allowed: false whenever a request would actually be denied -- which, for a rate limiter, is not a rare edge case, it's a routine and expected outcome that happens on essentially every deployment the moment any client exceeds its limit.

tb := ratelimit.NewTokenBucketRedis(client, 3, 1, "test:tb:") for i := 0; i < 3; i++ { tb.Allow(ctx, "user-1") } // fine, all 3 allowed tb.Allow(ctx, "user-1") // got: PANIC: interface conversion: interface {} is nil, not int64 // want: Result{Allowed: false, ...}, nil

This is a real, well-known Redis+Lua interop pitfall: Lua's false converts to a RESP nil reply when returned from a script, while Lua's true converts to the RESP integer 1. A Go caller that expects a consistent numeric type in that reply slot (vals[0].(int64)) gets a nil interface{} on the false case and a type assertion panic, not a zero/false value -- meaning the moment your rate limiter needs to say "no," it crashes the request instead.

Look at exactly how allowed is assigned and returned in pkg/ratelimit/lua/token_bucket.lua, and compare its type against the number 0/1 convention that pkg/ratelimit/lua/leaky_bucket.lua and pkg/ratelimit/lua/sliding_window.lua both still use correctly for the same field, and that the Go side already assumes (vals[0].(int64) == 1). Fix the Lua script's return value, not the Go type assertion.