FA-73453 / Rate limiter algorithms / Member archive

Sliding-window log limiter: late timestamp rewinds the limiter clock · case 03

A delayed request is evaluated in the past and resurrects expired entries.

Member previewVariant 3 · 3 implementations · 6 checks per implementation

Case contract

Input {limit, window_ms, requests [t]}. The limiter clock is now = max of all timestamps seen, so a late request is evaluated at now. Log entries with s <= now - W are pruned. Allow while fewer than limit entries remain and log now; denials are not logged and report retry = oldest + W - now. Return [[decision, retry]], final log].

Why this case matters

Sliding logs give exact rolling-window limits for login attempts and expensive endpoints; pruning and logging rules decide exactly when a client may retry.

One recorded failure

Sample boundary fixture

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

Boundary fixture	Actual	Expected	Outcome
late timestamp uses monotonic now	`[[["allow", 0], ["allow", 0], ["deny", 797], ["allow", 0], ["deny", 45], ["allow", 0]], [900, 960]]`	`[[["allow", 0], ["allow", 0], ["deny", 450], ["allow", 0], ["deny", 45], ["allow", 0]], [900, 960]]`	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.