You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Governor's rate-limiting needs a deterministic backoff/jitter calculator BEFORE it can be wired into any real enforcement path. This issue is the pure math only: given a bucket state (count, window, limit) and a clock reading, return the next-allowed-at time and a jittered retry delay — no storage, no scheduling, no actual blocking of a write action.
The existing RateLimiter Durable Object in src/auth/rate-limit.ts is a SERVER-side, Cloudflare-specific limiter and is NOT reusable client-side (the miner is 100% local, per the architecture skeleton) — so this is new local logic, but the bucket math and jittered-retry shape should mirror CONFIG/RateLimitDecision's fields for consistency of vocabulary.
Deliverables
New pure module (e.g. packages/gittensory-engine/src/governor/rate-limit.ts) exporting a LocalRateBucket type and evaluateLocalRateLimit(bucket, config, nowMs) returning { allowed, remaining, resetAtMs, retryAfterMs }
A jitter function jitteredBackoffMs(baseMs, attempt, randomFn) that takes an injectable random source (never calls Math.random() directly) so it stays unit-testable and deterministic in tests
Unit tests: under-limit passes, at-limit blocks, window-reset clears the bucket, jitter stays within the expected multiplicative band across a swept range of attempt values
A short doc comment stating explicitly this module computes numbers only — it does not itself gate any write action (that wiring is a separate, maintainer-owned issue)
References
src/auth/rate-limit.ts (207 lines) — the server-side RateLimitConfig/RateLimitDecision vocabulary to mirror (not reuse — that one is a Cloudflare Durable Object)
packages/gittensory-engine/ — new shared engine package housing this pure logic
The Governor's rate-limiting needs a deterministic backoff/jitter calculator BEFORE it can be wired into any real enforcement path. This issue is the pure math only: given a bucket state (count, window, limit) and a clock reading, return the next-allowed-at time and a jittered retry delay — no storage, no scheduling, no actual blocking of a write action.
The existing
RateLimiterDurable Object insrc/auth/rate-limit.tsis a SERVER-side, Cloudflare-specific limiter and is NOT reusable client-side (the miner is 100% local, per the architecture skeleton) — so this is new local logic, but the bucket math and jittered-retry shape should mirrorCONFIG/RateLimitDecision's fields for consistency of vocabulary.Deliverables
packages/gittensory-engine/src/governor/rate-limit.ts) exporting aLocalRateBuckettype andevaluateLocalRateLimit(bucket, config, nowMs)returning{ allowed, remaining, resetAtMs, retryAfterMs }jitteredBackoffMs(baseMs, attempt, randomFn)that takes an injectable random source (never callsMath.random()directly) so it stays unit-testable and deterministic in testsattemptvaluesReferences
src/auth/rate-limit.ts(207 lines) — the server-sideRateLimitConfig/RateLimitDecisionvocabulary to mirror (not reuse — that one is a Cloudflare Durable Object)packages/gittensory-engine/— new shared engine package housing this pure logic