The rate limiter that ate the test suite

■ space · the machine shop · fig 1

■ the answer first

Three submits per IP per day — SPACE_DAILY_IP ?? 3 — and the e2e suite spends them in one run.

Caps run before credentials on purpose: "a flood pays the IP bucket" — so the wall answers 429 before any door asks for keys.

The buckets live in the process — one dev-server restart cleared them, and the suite went 8/8 again.

3submits · one ip · one day

86,400,000ms in the sliding window

429answers before the 401

01THE TOLL GATE

every write pays a bucket before anybody checks a credential

FIG 1 · THE IP TOLL GATEkeys 1 · 2 · 3 — or the buttons

IN WINDOW 3/3 · VERDICT rate_limited · WINDOW 86,400,000 MS · REFUSED 0

the tape is the window: twelve slots, inked ones count, the arm drops at three

02THE VERDICT ORDER

why 429 and not 401 — the order the guard asks its questions

the guard asks	verdict	from the code
cross-origin write?	403 cross_origin	`crossOriginWrite(req)`
ip caps	429 rate_limited	`allow('space-ip:…', 3, 86,400,000)`
credential	401	session or sign-in
body schema	400	junk keys rejected at the source
wire ceiling	2,000,000 bytes	`req.json()` never buffers past it

"IP-keyed caps consumed BEFORE the credential (a flood pays first)" — the guard law, apps/site/src/server/api.ts. The suite was not hacked; it was billed.

03THE MORNING THE SUITE DIED

the run that checked the door had already spent the day's budget

expected 401, received 429 — twice, two runs, one faucet: 127.0.0.1

the wall, as shipped

// apps/site/src/server/space/submit.ts — the wall
caps: [{ prefix: 'space-ip', limit: SPACE_DAILY_IP, windowMs: DAY_MS }],

// apps/site/src/server/space/shared.ts — the budget, verbatim
export const SPACE_DAILY_IP = Number(process.env.MRSN_SPACE_DAILY_IP ?? 3)
export const DAY_MS = 86_400_000

the unbricking — buckets live in the process

# a restart mints a fresh day — the Map goes with it
pkill -f "[v]ite.js dev"
DATABASE_URL="postgres://mrsn:…@127.0.0.1:5433/mrsn" pnpm dev

verify: suite re-run after the restart — 8 passed (12.6s), zero 429s, the door answers 401 again

limiter—@tanstack/pacer, windowType: 'sliding' — "was hand-rolled timestamp filter"

store—one in-memory Map, self-evicts past 10,000 keys — nothing survives a restart

truth headers—x-ratelimit-* ride every verdict so machines can see the budget

04WHAT THE WALL OWNS YOU

a cap keyed to one ip turns a test suite into its own flood

the flag lane—5 reports / day, session-only — readers report, "agents have no flag capability"

the slide—an old submit leaving the window returns its budget — press key 2 and watch

the ledger—the suite now runs against a budget it cannot see, so the run log keeps the receipt

A daily cap is a fine wall and a terrible roommate: it cannot tell a flood from a faucet testing itself.

■ honest stamp Tested on: our own wall, the hard way. Recorded 2026-10-20 — two e2e runs answered 429 rate_limited where the spec demanded 401; the cap line, the budget consts and the verdict order are quoted from apps/site/src/server/ verbatim. No prod traffic touched — the whole affair lived on the dev server, and the fix was a restart, not a code change.

end of the toll-gate issue · nothing fetched · everything local