Understand the failure.
Verify the repair.
Small, reproducible software failures. The broken implementation, the fix that didn’t work, and the one that passed—preserved together.
Explore the cases ↓How results are verified ↗WHAT THE ARCHIVE CONTAINS
100840 executable cases. 20168 are open.
Every case records the implementation that fails, the fix that did not work, and the repair that passed its checks—with recorded outputs and source hashes. This release adds 100840 cases across 20168 failure mechanisms and 254 domains.
The open tier gives you the failure and the unsuccessful fix for one case in every mechanism. The remaining 80672 cases, 5 variants per mechanism, are member-only: the verified repair, its recorded checks, and the full fixture suite are held in the member archive. Read the methodology ↗
A RECORD OF WHAT WENT WRONG
Browse the archive / 100840
DGIM sliding-window bit counting: three buckets of a size allowed · case 01
The histogram holds more buckets than the invariant allows and estimates change.
DGIM sliding-window bit counting: three buckets of a size allowed · case 02
The histogram holds more buckets than the invariant allows and estimates change.
DGIM sliding-window bit counting: three buckets of a size allowed · case 03
The histogram holds more buckets than the invariant allows and estimates change.
DGIM sliding-window bit counting: three buckets of a size allowed · case 04
The histogram holds more buckets than the invariant allows and estimates change.
DGIM sliding-window bit counting: three buckets of a size allowed · case 05
The histogram holds more buckets than the invariant allows and estimates change.
DGIM sliding-window bit counting: merge does not cascade · case 01
After a merge, three buckets of the doubled size can coexist.
DGIM sliding-window bit counting: merge does not cascade · case 02
After a merge, three buckets of the doubled size can coexist.
DGIM sliding-window bit counting: merge does not cascade · case 03
After a merge, three buckets of the doubled size can coexist.
DGIM sliding-window bit counting: merge does not cascade · case 04
After a merge, three buckets of the doubled size can coexist.
DGIM sliding-window bit counting: merge does not cascade · case 05
After a merge, three buckets of the doubled size can coexist.
DGIM sliding-window bit counting: bucket at the window edge not expired · case 01
A 1 that is exactly W ticks old is still counted.
DGIM sliding-window bit counting: bucket at the window edge not expired · case 02
A 1 that is exactly W ticks old is still counted.
DGIM sliding-window bit counting: bucket at the window edge not expired · case 03
A 1 that is exactly W ticks old is still counted.
DGIM sliding-window bit counting: bucket at the window edge not expired · case 04
A 1 that is exactly W ticks old is still counted.
DGIM sliding-window bit counting: bucket at the window edge not expired · case 05
A 1 that is exactly W ticks old is still counted.
DGIM sliding-window bit counting: estimate halves the newest bucket · case 01
The uncertainty correction is applied to the fully-inside newest bucket instead of the straddling oldest one.
DGIM sliding-window bit counting: estimate halves the newest bucket · case 02
The uncertainty correction is applied to the fully-inside newest bucket instead of the straddling oldest one.
DGIM sliding-window bit counting: estimate halves the newest bucket · case 03
The uncertainty correction is applied to the fully-inside newest bucket instead of the straddling oldest one.
DGIM sliding-window bit counting: estimate halves the newest bucket · case 04
The uncertainty correction is applied to the fully-inside newest bucket instead of the straddling oldest one.
DGIM sliding-window bit counting: estimate halves the newest bucket · case 05
The uncertainty correction is applied to the fully-inside newest bucket instead of the straddling oldest one.
Top-k tracking over a Count-Min sketch: tracked scores never refreshed · case 01
An established leader keeps its entry score and is evicted by newer, smaller keys.
Top-k tracking over a Count-Min sketch: tracked scores never refreshed · case 02
An established leader keeps its entry score and is evicted by newer, smaller keys.
Top-k tracking over a Count-Min sketch: tracked scores never refreshed · case 03
An established leader keeps its entry score and is evicted by newer, smaller keys.
Top-k tracking over a Count-Min sketch: tracked scores never refreshed · case 04
An established leader keeps its entry score and is evicted by newer, smaller keys.
Top-k tracking over a Count-Min sketch: tracked scores never refreshed · case 05
An established leader keeps its entry score and is evicted by newer, smaller keys.
Top-k tracking over a Count-Min sketch: equal estimate replaces the minimum · case 01
Keys with equal estimates churn the table, and the reported leader set depends on arrival order.
Top-k tracking over a Count-Min sketch: equal estimate replaces the minimum · case 02
Keys with equal estimates churn the table, and the reported leader set depends on arrival order.
Top-k tracking over a Count-Min sketch: equal estimate replaces the minimum · case 03
Keys with equal estimates churn the table, and the reported leader set depends on arrival order.
Top-k tracking over a Count-Min sketch: equal estimate replaces the minimum · case 04
Keys with equal estimates churn the table, and the reported leader set depends on arrival order.
Top-k tracking over a Count-Min sketch: equal estimate replaces the minimum · case 05
Keys with equal estimates churn the table, and the reported leader set depends on arrival order.
Top-k tracking over a Count-Min sketch: tie among minima evicts the newest entry · case 01
Which minimum-score key survives depends on insertion history instead of the stated tie-break.
Top-k tracking over a Count-Min sketch: tie among minima evicts the newest entry · case 02
Which minimum-score key survives depends on insertion history instead of the stated tie-break.
Top-k tracking over a Count-Min sketch: tie among minima evicts the newest entry · case 03
Which minimum-score key survives depends on insertion history instead of the stated tie-break.
Top-k tracking over a Count-Min sketch: tie among minima evicts the newest entry · case 04
Which minimum-score key survives depends on insertion history instead of the stated tie-break.
Top-k tracking over a Count-Min sketch: tie among minima evicts the newest entry · case 05
Which minimum-score key survives depends on insertion history instead of the stated tie-break.
Top-k tracking over a Count-Min sketch: candidate scored before its own update · case 01
Each key is scored without its current occurrence, so newcomers can never beat equal incumbents.
Top-k tracking over a Count-Min sketch: candidate scored before its own update · case 02
Each key is scored without its current occurrence, so newcomers can never beat equal incumbents.
Top-k tracking over a Count-Min sketch: candidate scored before its own update · case 03
Each key is scored without its current occurrence, so newcomers can never beat equal incumbents.
Top-k tracking over a Count-Min sketch: candidate scored before its own update · case 04
Each key is scored without its current occurrence, so newcomers can never beat equal incumbents.
Top-k tracking over a Count-Min sketch: candidate scored before its own update · case 05
Each key is scored without its current occurrence, so newcomers can never beat equal incumbents.
Token bucket with lazy exact refill: refill not capped at capacity · case 01
After an idle period a client can burst far beyond the configured capacity.
Token bucket with lazy exact refill: refill not capped at capacity · case 02
After an idle period a client can burst far beyond the configured capacity.
Token bucket with lazy exact refill: refill not capped at capacity · case 03
After an idle period a client can burst far beyond the configured capacity.
Token bucket with lazy exact refill: refill not capped at capacity · case 04
After an idle period a client can burst far beyond the configured capacity.
Token bucket with lazy exact refill: refill not capped at capacity · case 05
After an idle period a client can burst far beyond the configured capacity.
Token bucket with lazy exact refill: backwards clock step drains tokens · case 01
A request stamped slightly earlier than the previous one removes tokens it never spent.
Token bucket with lazy exact refill: backwards clock step drains tokens · case 02
A request stamped slightly earlier than the previous one removes tokens it never spent.
Token bucket with lazy exact refill: backwards clock step drains tokens · case 03
A request stamped slightly earlier than the previous one removes tokens it never spent.
Token bucket with lazy exact refill: backwards clock step drains tokens · case 04
A request stamped slightly earlier than the previous one removes tokens it never spent.
Token bucket with lazy exact refill: backwards clock step drains tokens · case 05
A request stamped slightly earlier than the previous one removes tokens it never spent.
Token bucket with lazy exact refill: refill anchor rewinds on a late request · case 01
After a late timestamp the next request is credited again for time already refilled.
Token bucket with lazy exact refill: refill anchor rewinds on a late request · case 02
After a late timestamp the next request is credited again for time already refilled.
Token bucket with lazy exact refill: refill anchor rewinds on a late request · case 03
After a late timestamp the next request is credited again for time already refilled.
Token bucket with lazy exact refill: refill anchor rewinds on a late request · case 04
After a late timestamp the next request is credited again for time already refilled.
Token bucket with lazy exact refill: refill anchor rewinds on a late request · case 05
After a late timestamp the next request is credited again for time already refilled.
Token bucket with lazy exact refill: impossible cost reported with a finite wait · case 01
A request larger than the bucket is told to retry after a wait that can never be satisfied.
Token bucket with lazy exact refill: impossible cost reported with a finite wait · case 02
A request larger than the bucket is told to retry after a wait that can never be satisfied.
Token bucket with lazy exact refill: impossible cost reported with a finite wait · case 03
A request larger than the bucket is told to retry after a wait that can never be satisfied.
Token bucket with lazy exact refill: impossible cost reported with a finite wait · case 04
A request larger than the bucket is told to retry after a wait that can never be satisfied.
Token bucket with lazy exact refill: impossible cost reported with a finite wait · case 05
A request larger than the bucket is told to retry after a wait that can never be satisfied.
Token bucket with lazy exact refill: advertised wait rounds down · case 01
Clients that honour the advertised wait arrive a fraction of a millisecond early and are denied again.
Token bucket with lazy exact refill: advertised wait rounds down · case 02
Clients that honour the advertised wait arrive a fraction of a millisecond early and are denied again.
Token bucket with lazy exact refill: advertised wait rounds down · case 03
Clients that honour the advertised wait arrive a fraction of a millisecond early and are denied again.
Token bucket with lazy exact refill: advertised wait rounds down · case 04
Clients that honour the advertised wait arrive a fraction of a millisecond early and are denied again.
Token bucket with lazy exact refill: advertised wait rounds down · case 05
Clients that honour the advertised wait arrive a fraction of a millisecond early and are denied again.
Token bucket with lazy exact refill: exact balance is denied · case 01
A request whose cost exactly equals the refilled balance is denied.
Token bucket with lazy exact refill: exact balance is denied · case 02
A request whose cost exactly equals the refilled balance is denied.
Token bucket with lazy exact refill: exact balance is denied · case 03
A request whose cost exactly equals the refilled balance is denied.
Token bucket with lazy exact refill: exact balance is denied · case 04
A request whose cost exactly equals the refilled balance is denied.
Token bucket with lazy exact refill: exact balance is denied · case 05
A request whose cost exactly equals the refilled balance is denied.
Generic cell rate algorithm limiter: idle time banks unlimited credit · case 01
After a quiet period the limiter admits an unbounded burst because TAT lags far behind now.
Generic cell rate algorithm limiter: idle time banks unlimited credit · case 02
After a quiet period the limiter admits an unbounded burst because TAT lags far behind now.
Generic cell rate algorithm limiter: idle time banks unlimited credit · case 03
After a quiet period the limiter admits an unbounded burst because TAT lags far behind now.
Generic cell rate algorithm limiter: idle time banks unlimited credit · case 04
After a quiet period the limiter admits an unbounded burst because TAT lags far behind now.
Generic cell rate algorithm limiter: idle time banks unlimited credit · case 05
After a quiet period the limiter admits an unbounded burst because TAT lags far behind now.
Generic cell rate algorithm limiter: denied requests advance TAT · case 01
A client that keeps retrying is locked out indefinitely because rejected requests consume future capacity.
Generic cell rate algorithm limiter: denied requests advance TAT · case 02
A client that keeps retrying is locked out indefinitely because rejected requests consume future capacity.
Generic cell rate algorithm limiter: denied requests advance TAT · case 03
A client that keeps retrying is locked out indefinitely because rejected requests consume future capacity.
Generic cell rate algorithm limiter: denied requests advance TAT · case 04
A client that keeps retrying is locked out indefinitely because rejected requests consume future capacity.
Generic cell rate algorithm limiter: denied requests advance TAT · case 05
A client that keeps retrying is locked out indefinitely because rejected requests consume future capacity.
Generic cell rate algorithm limiter: burst tolerance one period short · case 01
Clients receive one request less than the configured burst.
Generic cell rate algorithm limiter: burst tolerance one period short · case 02
Clients receive one request less than the configured burst.
Generic cell rate algorithm limiter: burst tolerance one period short · case 03
Clients receive one request less than the configured burst.
Generic cell rate algorithm limiter: burst tolerance one period short · case 04
Clients receive one request less than the configured burst.
Generic cell rate algorithm limiter: burst tolerance one period short · case 05
Clients receive one request less than the configured burst.
Generic cell rate algorithm limiter: retry-after ignores the burst tolerance · case 01
Denied clients are told to wait far longer than necessary.
Generic cell rate algorithm limiter: retry-after ignores the burst tolerance · case 02
Denied clients are told to wait far longer than necessary.
Generic cell rate algorithm limiter: retry-after ignores the burst tolerance · case 03
Denied clients are told to wait far longer than necessary.
Generic cell rate algorithm limiter: retry-after ignores the burst tolerance · case 04
Denied clients are told to wait far longer than necessary.
Generic cell rate algorithm limiter: retry-after ignores the burst tolerance · case 05
Denied clients are told to wait far longer than necessary.
Generic cell rate algorithm limiter: multi-unit request charged as one · case 01
A request for several units consumes only one emission interval, multiplying the admitted rate.
Generic cell rate algorithm limiter: multi-unit request charged as one · case 02
A request for several units consumes only one emission interval, multiplying the admitted rate.
Generic cell rate algorithm limiter: multi-unit request charged as one · case 03
A request for several units consumes only one emission interval, multiplying the admitted rate.
Generic cell rate algorithm limiter: multi-unit request charged as one · case 04
A request for several units consumes only one emission interval, multiplying the admitted rate.
Generic cell rate algorithm limiter: multi-unit request charged as one · case 05
A request for several units consumes only one emission interval, multiplying the admitted rate.
Generic cell rate algorithm limiter: oversize check compares units with time · case 01
Requests larger than the burst receive retry hints that can never succeed.
Generic cell rate algorithm limiter: oversize check compares units with time · case 02
Requests larger than the burst receive retry hints that can never succeed.
Generic cell rate algorithm limiter: oversize check compares units with time · case 03
Requests larger than the burst receive retry hints that can never succeed.
Generic cell rate algorithm limiter: oversize check compares units with time · case 04
Requests larger than the burst receive retry hints that can never succeed.
Generic cell rate algorithm limiter: oversize check compares units with time · case 05
Requests larger than the burst receive retry hints that can never succeed.
INSPECTABLE BY DESIGN
Every result has a runnable source.
Runnable implementations with recorded outputs, source hashes, and explicit contracts. Related variants share a failure mechanism and belong together in evaluation splits.
Read the methodology ↗