FA-73689 / Rate limiter algorithms / Member archive

Priority limiter with reserved high-priority capacity: unknown labels treated as high · case 04

Batch jobs tagged with a new label bypass the reserve and consume capacity meant for critical traffic.

Member previewVariant 4 · 3 implementations · 7 checks per implementation

Case contract

Input {capacity, reserved_high, requests [[t_ms, priority]]} with nondecreasing t, one-second epoch windows. Only the exact label "high" is high priority; every other label is low. A high request is admitted while total admitted < capacity. A low request is admitted only while admitted low < capacity - reserved_high and total < capacity. Both counters reset each window. Return [decisions, [low, high] of the final window].

Why this case matters

Shared limiters reserve headroom for critical traffic (health checks, payments) so that bulk clients cannot starve it; the reserve arithmetic decides whether the guarantee holds.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixture	Actual	Expected	Outcome
unknown priority is low	`[["allow", "allow", "allow", "deny", "deny"], [3, 0]]`	`[["allow", "allow", "deny", "allow", "deny"], [2, 1]]`	Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.