FA-73599 / Rate limiter algorithms / Member archive

Concurrency limiter with expiring leases: expiry runs only on acquire · case 04

Releasing an already expired lease is reported as a successful release.

Member previewVariant 4 · 3 implementations · 6 checks per implementation

Case contract

Input {max_concurrent, lease_ms, events [[t, op, id]]}. Before every event, leases with start + lease_ms <= t expire. acquire returns "duplicate" (no change) for a held id, "granted" (recording t) when fewer than max_concurrent leases are held, else "rejected". release returns "released" for a held id and "unknown" otherwise, changing nothing. Return [results, sorted held ids].

Why this case matters

Concurrency limiters for workers and database pools use leases so that crashed holders eventually free their slot; expiry and release bookkeeping determine whether slots leak or double-count.

One recorded failure

Sample boundary fixture

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

Boundary fixture	Actual	Expected	Outcome
release after expiry	`[["granted", "released", "granted"], ["b"]]`	`[["granted", "unknown", "granted"], ["b"]]`	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.