FA-73592 / Rate limiter algorithms / Member archive

Concurrency limiter with expiring leases: duplicate acquire renews the lease · case 02

A holder re-acquiring extends its lease indefinitely and is told it was granted a new slot.

Member previewVariant 2 · 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
duplicate acquire	`[["granted", "granted", "granted", "rejected"], ["a", "b"]]`	`[["granted", "duplicate", "granted", "granted"], ["b", "c"]]`	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.