[chappie-daemon]

Closes #1006. Follow-up to the spike in #1004.

1. The EWMA backoff is now the time the limit actually takes to lift

RateLimit.period is the decay half-life under ewma (src/utils/ewma-rate-limiter.ts), so the time until an event is accepted again is period · log2(R_new / rate) — and we were sending period. With rate: 6, period: 60000 and a score of 24, the next hit is accepted once the score decays to rate - step = 5, which takes 60000 · log2(24/5) ≈ 136 s — and we were sending 60 s. (rate - step, not rate: the script adds this hit's step before comparing.)

The Lua script now returns its score (tostring, because a Lua number reaches the client truncated to an integer) instead of 0/1, and the limiter computes the wait. A non-numeric or nil answer is a protocol disagreement, not a score of zero, so it throws and the caller fails closed rather than silently disabling the limiter.

It was safe only by accident before: the hash carried a TTL of exactly period, so a quiet client's state expired anyway. When rate <= step no decay can admit another hit, and the answer is one period — the same TTL. That coupling was unstated, and lengthening the TTL to keep state warm would have exposed the wrong number.

2. An outage is an error, not a rate limit

isRateLimited caught a backend failure and returned the same value as a tripped limit, so the client got rate-limited: slow down with no parameter — and every connected client backed off at once for a fault on this side. The branch now answers:

["OK", <id>, false, "error: rate limiter unavailable"]

Fail-closed behaviour is unchanged: the event is still rejected. Only the reason is honest.

3. The message bucket carries the message type

One bucket per client meant a REQ could be refused because its EVENTs had filled it — the wrong message throttled and the wrong one told to back off. The bucket is now <client>:message:<TYPE>:<period>.

The type comes from a bounded prefix of the frame rather than a full parse, because the limiter runs before validation and must not be the thing that spends the parse budget. It is a closed set — REQ, EVENT, COUNT, CLOSE, AUTH, NEG-OPEN, NEG-MSG, NEG-CLOSE — and anything else shares one OTHER bucket: an arbitrary word would let a client rotate invented types (["AAAA"], ["BBBB"], …) and keep every bucket empty.

This changes the bucket layout: any in-flight window under the old key is simply abandoned, which costs one window of enforcement and nothing else.

Interface

IRateLimiter.hit returns IRateLimiterResult:

export interface IRateLimiterResult {
  limited: boolean
  retryAfterMs?: number   // absent when the strategy cannot estimate one
}

Absence means "limited, no estimate" and is never read as "retry now". The sliding window sends period — the honest upper bound, since the oldest hit ages out within one window — and EWMA sends the computed half-life backoff. The event handler and the socket adapter share the fallback (retryAfterMs ?? period).

Verification

• test/unit/utils/ewma-rate-limiter.spec.ts — 13 passing, including the 135783 ms case, a fractional score (6.4 must not arrive as 6), and no headroom (rate: 1, step: 1)
• test/unit/handlers/event-message-handler.spec.ts — 242 passing, including the new outage case
• test/unit/adapters/web-socket-adapter.spec.ts — 69 passing, including a per-type bucket test, an invented-type test, and one that the strategy's own estimate wins over the period
• test/unit/utils/sliding-window-rate-limiter.spec.ts, test/unit/utils/admin-rate-limit.spec.ts, test/unit/controllers/invoices/post-invoice-controller.spec.ts, test/unit/handlers/subscribe-message-handler.spec.ts — green

Local runs used TS_NODE_TRANSPILE_ONLY=1 because this checkout's node_modules is a partial install (@cucumber/cucumber types are absent), so CI is the type-check gate.

Out of scope

The sliding window's retryAfterMs stays period. Narrowing it to oldest hit + period - now is a second Redis round trip on the hot path, and the value is already an upper bound rather than a wrong one.

Review

Greptile's three P1s on the first draft were all correct and are fixed in 15ae7a9: the closed set of message types, the rate - step target, and get-subscription-status-controller.ts:127, which still read the result object as a boolean and would have answered 429 to every request. Its threads are resolved.

[changeset-bot]

🦋 Changeset detected

Latest commit: 15ae7a9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
nostream	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The latest changes appear safe to merge; no new blocking issue was established.

Summary

Updates rate-limit replies and moves callers to the result object returned by hit.

• Rate-limit results include the wait each strategy can estimate.
• WebSocket rate limits keep each known message type in its own bucket.
• Event submissions report limiter outages as errors, not rate limits.

The three supplied previous threads are unnumbered, so they have no previousFindings entries. No new actionable issue was established in the latest changes.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Incoming message] --> B[Choose known type or OTHER]
  B --> C[Hit the type's rate-limit bucket]
  C --> D{Limit exceeded?}
  D -->|No| E[Validate and handle message]
  D -->|Yes| F[Use estimated wait or period]
  F --> G[Send refusal]

Loading

_{Reviews (3) · Last reviewed commit: "fix(rate-limit): a closed set of message..." · Reviewed by Greptile}

[coveralls]

Coverage Report for CI Build 41242089027

Coverage increased (+0.04%) to 77.402%

Details

• Coverage increased (+0.04%) from the base build.
• Patch coverage: 3 uncovered changes across 3 files (45 of 48 lines covered, 93.75%).
• No coverage regressions found.

Uncovered Changes

File	Changed	Covered	%
src/controllers/admission/get-admission-check-controller.ts	1	0	0.0%
src/handlers/request-handlers/rate-limiter-middleware.ts	1	0	0.0%
src/utils/ewma-rate-limiter.ts	11	10	90.91%
Total (10 files)	48	45	93.75%

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	11841
Covered Lines:	9577
Line Coverage:	80.88%
Relevant Branches:	6227
Covered Branches:	4408
Branch Coverage:	70.79%
Branches in Coverage %:	Yes
Coverage Strength:	772.83 hits per line

---

💛 - Coveralls