fix(limits): correct dangling comments and redisStore edge cases

Independent review round approved the fusion itself (11 to 3 RTT/req,
precedence verified branch by branch, latch/fail-open checked under
Yaegi against a dead Redis). This commit addresses the follow-up items
raised against that same change.

Six doc comments in limits.go still named evaluateScope,
budgetViolation, or tokenBudgetViolation as if they were live
functions to consult. All three were removed by the fusion commit; the
comments now point at checkAndCount and buildBudgetProbes, where the
same logic lives today. One further comment claimed checkAndCount
still slices a "storeIncrMulti result" — it now slices
storeIncrAndGetMulti's own incrVals.

TestCheckAndCount_FusedViolationPrecedence's doc comment claimed every
subtest engineers two simultaneous violation conditions. The seventh
engineers only one (the group violates; the user carries no limits at
all) — it pins a different claim, that a later scope is still
evaluated when an earlier one has nothing to check. The comment now
says so.

redisStore.incrAndGetMulti gained the same len()==0 guard incrMulti
already has, and a table-driven test proves a RESP error or a
non-integer value on a read key fails the whole call, matching
respClient.getBatch's own equivalent table.

Re-ran the interpreted Yaegi harness after these changes: RTT/req
stays at 3.00, cmds/req stays at 74.00 — the fusion's throughput win is
unaffected by this round's fixes.
This commit is contained in:
2026-08-22 12:14:48 +01:00
parent e3ef4084d2
commit 311dd20a8e
4 changed files with 93 additions and 14 deletions
+9 -3
View File
@@ -1320,9 +1320,15 @@ func TestTokenBudget_ExactBoundaryViolates(t *testing.T) {
// within one scope, requests-per-minute, then requests-per-day, then
// tokens-per-day, then tokens-per-month, then cost-per-day, then
// cost-per-month; across scopes, the scope earlier in the given slice
// (buildLimitScopes puts a user before their group) wins. Every subtest
// engineers TWO simultaneously-true violation conditions and asserts only
// the higher-precedence one is ever reported.
// (buildLimitScopes puts a user before their group) wins. The first six
// subtests each engineer TWO simultaneously-true violation conditions
// (one per limit type in a precedence pair) and assert only the
// higher-precedence one is ever reported; the seventh engineers only ONE
// condition (the group violates, the user carries no limits at all) to
// pin the separate claim that a later scope still gets evaluated at all
// when an earlier one has nothing to check (review fix, 2026-08-22, round
// 2: this doc comment previously claimed all seven subtests engineered
// two conditions, which was not true of the seventh).
func TestCheckAndCount_FusedViolationPrecedence(t *testing.T) {
t.Run("requests-per-minute beats requests-per-day in the same scope", func(t *testing.T) {
l := newLimiter(nil, true)