Eviction has one edge that decides borderline requests - is a timestamp sitting exactly at the cutoff still counted, or has it aged out? Today you pin that boundary precisely so the log allows and denies on the exact right tick.
Pin whether a timestamp exactly window ticks old still counts.
Every windowed limiter has to answer one borderline question: when a request is
exactly one window old, is it in or out? Getting this off by a single tick shifts
every decision near a boundary, so pin it. We define the trailing window as
half-open: (now - window, now]. A timestamp counts only if it is strictly
greater than now - window; an entry sitting exactly on the cutoff has aged out.
Watch it decide two adjacent ticks. With limit 1 and one request logged at tick 0:
at tick 9 the cutoff is -1, the entry 0 is greater than -1 so it still counts, the
single slot is full, and the request is denied. One tick later, at tick 10, the
cutoff is 0, the entry 0 is not greater than 0, so it ages out, the slot frees,
and the request is allowed. The allowance returns at exactly tick 10, not tick 9
The boundary is not special to tick 0 - it slides with every entry. The request that got in at tick 10 records its own timestamp, and it in turn ages out exactly a window later: at tick 19 it still counts (denied), at tick 20 it has aged out (allowed). Pin both boundaries so the half-open rule is locked in wherever an entry lands on the clock.
// the trailing window is half-open: (now - window, now].// keep t only if t > now - window (strictly greater).cutoff := now - s.windowif t > cutoff {// still inside the window}// at now=10, window=10: cutoff 0; entry 0 is NOT > 0 -> evicted