Leaky bucket fills instead of draining

This algorithm guards login-brute-force-guard -- i.e. it sits directly on the login page, the single most trafficked, most first-impression-critical path in the product. A bug that turns a temporary slow-down into a permanent lockout means any legitimate user who ever tried logging in 5 times in a row (a mistyped password, a forgotten password, a shared office IP with several people logging in) is locked out forever, with no recovery except an operator restarting the whole service -- which resets everyone's state, not just theirs. This reads to customers as "the login page is broken," generates a support ticket per affected user, and can plausibly look like a full outage even though every other system is healthy. It is a self-inflicted denial-of-service against your own users, on the path they hit first.

The leaky bucket is supposed to "leak" -- its fill level should decrease over time at leakRate units/sec, so a key that stops sending requests eventually becomes free to send again. Right now the level only ever goes up over time, never down. Once any key's bucket fills to capacity, it is rate-limited forever, even after it stops sending requests entirely.

lb := ratelimit.NewLeakyBucketMemory(1, 50 /* drains 50/sec */, time.Minute) lb.Allow(ctx, "user-1") // allowed, level now 1 (at capacity) lb.Allow(ctx, "user-1") // denied, as expected (over capacity) time.Sleep(30 * time.Millisecond) // at 50 units/sec, 1.5 units of drain -- more than enough lb.Allow(ctx, "user-1") // got: still denied, and RetryAfter keeps growing no matter how long you wait // want: Allowed: true -- the bucket had time to drain

The seeded login-brute-force-guard rule (leaky bucket, capacity 5, drains 1/10sec) is meant to slow down repeated login attempts, not permanently ban every IP that ever tried to log in 5 times. With this bug live, the first burst of 5 login attempts from any legitimate user permanently locks that IP/key out of /demo/login for the lifetime of the process (or until the janitor's idle-TTL eviction happens to clear it, a much longer, unrelated timescale). This is a self-inflicted denial-of-service against your own users.

One arithmetic operator, where elapsed time is combined with lb.leakRate to update e.level. Compare against the in-memory token bucket's refill line just above it in the sibling file (pkg/ratelimit/token_bucket.go) for the mirror-image case (tokens go up over time there; level should go down here) -- and against the Redis Lua script pkg/ratelimit/lua/leaky_bucket.lua, which already does this correctly and is not part of this bug.