FAILURE MAP
← Case archive

FA-73604 / Rate limiter algorithms / Member archive

Escalating failure penalty box: ban still active at its end instant · case 04

A client retrying exactly when told the ban ends is still refused.

Member previewVariant 4 · 3 implementations · 7 checks per implementation

Case contract

Input {threshold, window_s, ban_s, events [[t, ok]]} with nondecreasing t. While t < ban end every event is "banned" and ignored. Failures are kept for window_s seconds (f > t - window_s). When the kept failures reach threshold the key is banned until t + ban_s * 2^strikes, strikes increments and the failure log is cleared; the event reports "ban-until-<end>". Otherwise failures report "fail" and successes "ok". Return the per-event results.

Why this case matters

Login and abuse throttles escalate bans after repeated failures; window, escalation and log-reset rules decide whether attackers are slowed and legitimate users recover.

One recorded failure

Sample boundary fixture

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

Boundary fixtureActualExpectedOutcome
ban and escalate["fail", "fail", "ban-until-12", "banned", "banned", "fail", "fail", "ban-until-54", "banned"]["fail", "fail", "ban-until-12", "banned", "fail", "fail", "ban-until-34", "fail", "ok"]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.

Sign in to the archive ↗