FA-73584 / Rate limiter algorithms / Member archive

Concurrency limiter with expiring leases: lease still held at its expiry instant · case 04

A slot stays occupied one tick past its lease, rejecting a waiting acquirer.

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
lease expires exactly	`[["granted", "rejected", "rejected", "unknown"], []]`	`[["granted", "rejected", "granted", "released"], []]`	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.