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
Combined per-second and per-minute fixed windows: minute counter resets every second · case 01
The per-minute limit is never reached because it is cleared whenever a new second starts.
Combined per-second and per-minute fixed windows: minute counter resets every second · case 02
The per-minute limit is never reached because it is cleared whenever a new second starts.
Combined per-second and per-minute fixed windows: minute counter resets every second · case 03
The per-minute limit is never reached because it is cleared whenever a new second starts.
Combined per-second and per-minute fixed windows: minute counter resets every second · case 04
The per-minute limit is never reached because it is cleared whenever a new second starts.
Combined per-second and per-minute fixed windows: minute counter resets every second · case 05
The per-minute limit is never reached because it is cleared whenever a new second starts.
Combined per-second and per-minute fixed windows: minute denial consumes the second budget · case 01
Requests rejected by the minute limit also exhaust the per-second allowance.
Combined per-second and per-minute fixed windows: minute denial consumes the second budget · case 02
Requests rejected by the minute limit also exhaust the per-second allowance.
Combined per-second and per-minute fixed windows: minute denial consumes the second budget · case 03
Requests rejected by the minute limit also exhaust the per-second allowance.
Combined per-second and per-minute fixed windows: minute denial consumes the second budget · case 04
Requests rejected by the minute limit also exhaust the per-second allowance.
Combined per-second and per-minute fixed windows: minute denial consumes the second budget · case 05
Requests rejected by the minute limit also exhaust the per-second allowance.
Combined per-second and per-minute fixed windows: minute window computed from milliseconds as seconds · case 01
The minute counter resets every 60 ms and the minute limit is never effective.
Combined per-second and per-minute fixed windows: minute window computed from milliseconds as seconds · case 02
The minute counter resets every 60 ms and the minute limit is never effective.
Combined per-second and per-minute fixed windows: minute window computed from milliseconds as seconds · case 03
The minute counter resets every 60 ms and the minute limit is never effective.
Combined per-second and per-minute fixed windows: minute window computed from milliseconds as seconds · case 04
The minute counter resets every 60 ms and the minute limit is never effective.
Combined per-second and per-minute fixed windows: minute window computed from milliseconds as seconds · case 05
The minute counter resets every 60 ms and the minute limit is never effective.
Combined per-second and per-minute fixed windows: minute limit reported first · case 01
Clients exhausted on both limits are told to wait for the minute reset instead of the next second.
Combined per-second and per-minute fixed windows: minute limit reported first · case 02
Clients exhausted on both limits are told to wait for the minute reset instead of the next second.
Combined per-second and per-minute fixed windows: minute limit reported first · case 03
Clients exhausted on both limits are told to wait for the minute reset instead of the next second.
Combined per-second and per-minute fixed windows: minute limit reported first · case 04
Clients exhausted on both limits are told to wait for the minute reset instead of the next second.
Combined per-second and per-minute fixed windows: minute limit reported first · case 05
Clients exhausted on both limits are told to wait for the minute reset instead of the next second.
Max-min fair split of a global rate limit: share divided among satisfied clients too · case 01
Capacity is split among clients that no longer need it, needing extra rounds and misallocating the remainder.
Max-min fair split of a global rate limit: share divided among satisfied clients too · case 02
Capacity is split among clients that no longer need it, needing extra rounds and misallocating the remainder.
Max-min fair split of a global rate limit: share divided among satisfied clients too · case 03
Capacity is split among clients that no longer need it, needing extra rounds and misallocating the remainder.
Max-min fair split of a global rate limit: share divided among satisfied clients too · case 04
Capacity is split among clients that no longer need it, needing extra rounds and misallocating the remainder.
Max-min fair split of a global rate limit: share divided among satisfied clients too · case 05
Capacity is split among clients that no longer need it, needing extra rounds and misallocating the remainder.
Max-min fair split of a global rate limit: allocation exceeds demand · case 01
Light clients receive rate they cannot use while heavy clients are starved.
Max-min fair split of a global rate limit: allocation exceeds demand · case 02
Light clients receive rate they cannot use while heavy clients are starved.
Max-min fair split of a global rate limit: allocation exceeds demand · case 03
Light clients receive rate they cannot use while heavy clients are starved.
Max-min fair split of a global rate limit: allocation exceeds demand · case 04
Light clients receive rate they cannot use while heavy clients are starved.
Max-min fair split of a global rate limit: allocation exceeds demand · case 05
Light clients receive rate they cannot use while heavy clients are starved.
Max-min fair split of a global rate limit: indivisible remainder discarded · case 01
A few units of capacity are left unused even though clients still want them.
Max-min fair split of a global rate limit: indivisible remainder discarded · case 02
A few units of capacity are left unused even though clients still want them.
Max-min fair split of a global rate limit: indivisible remainder discarded · case 03
A few units of capacity are left unused even though clients still want them.
Max-min fair split of a global rate limit: indivisible remainder discarded · case 04
A few units of capacity are left unused even though clients still want them.
Max-min fair split of a global rate limit: indivisible remainder discarded · case 05
A few units of capacity are left unused even though clients still want them.
Max-min fair split of a global rate limit: zero-demand clients dilute the first share · case 01
Clients that asked for nothing shrink everyone else's first-round share and can receive remainder units.
Max-min fair split of a global rate limit: zero-demand clients dilute the first share · case 02
Clients that asked for nothing shrink everyone else's first-round share and can receive remainder units.
Max-min fair split of a global rate limit: zero-demand clients dilute the first share · case 03
Clients that asked for nothing shrink everyone else's first-round share and can receive remainder units.
Max-min fair split of a global rate limit: zero-demand clients dilute the first share · case 04
Clients that asked for nothing shrink everyone else's first-round share and can receive remainder units.
Max-min fair split of a global rate limit: zero-demand clients dilute the first share · case 05
Clients that asked for nothing shrink everyone else's first-round share and can receive remainder units.
Percentage rollout gate: User and flag swap places in the hash key · case 01
Users land in different buckets than every other SDK computes for the same flag.
Percentage rollout gate: User and flag swap places in the hash key · case 02
Users land in different buckets than every other SDK computes for the same flag.
Percentage rollout gate: User and flag swap places in the hash key · case 03
Users land in different buckets than every other SDK computes for the same flag.
Percentage rollout gate: User and flag swap places in the hash key · case 04
Users land in different buckets than every other SDK computes for the same flag.
Percentage rollout gate: User and flag swap places in the hash key · case 05
Users land in different buckets than every other SDK computes for the same flag.
Percentage rollout gate: Seven hex digits feed the bucket · case 01
Bucket numbers disagree with the reference for most users while still looking uniform.
Percentage rollout gate: Seven hex digits feed the bucket · case 02
Bucket numbers disagree with the reference for most users while still looking uniform.
Percentage rollout gate: Seven hex digits feed the bucket · case 03
Bucket numbers disagree with the reference for most users while still looking uniform.
Percentage rollout gate: Seven hex digits feed the bucket · case 04
Bucket numbers disagree with the reference for most users while still looking uniform.
Percentage rollout gate: Seven hex digits feed the bucket · case 05
Bucket numbers disagree with the reference for most users while still looking uniform.
Percentage rollout gate: A user whose bucket equals the limit is enabled · case 01
Rollouts expose one extra basis point of traffic, and 0 percent still enables bucket zero.
Percentage rollout gate: A user whose bucket equals the limit is enabled · case 02
Rollouts expose one extra basis point of traffic, and 0 percent still enables bucket zero.
Percentage rollout gate: A user whose bucket equals the limit is enabled · case 03
Rollouts expose one extra basis point of traffic, and 0 percent still enables bucket zero.
Percentage rollout gate: A user whose bucket equals the limit is enabled · case 04
Rollouts expose one extra basis point of traffic, and 0 percent still enables bucket zero.
Percentage rollout gate: A user whose bucket equals the limit is enabled · case 05
Rollouts expose one extra basis point of traffic, and 0 percent still enables bucket zero.
Percentage rollout gate: Float truncation shrinks fractional rollout limits · case 01
A 0.29 percent rollout admits only 28 basis points of buckets.
Percentage rollout gate: Float truncation shrinks fractional rollout limits · case 02
A 0.29 percent rollout admits only 28 basis points of buckets.
Percentage rollout gate: Float truncation shrinks fractional rollout limits · case 03
A 0.29 percent rollout admits only 28 basis points of buckets.
Percentage rollout gate: Float truncation shrinks fractional rollout limits · case 04
A 0.29 percent rollout admits only 28 basis points of buckets.
Percentage rollout gate: Float truncation shrinks fractional rollout limits · case 05
A 0.29 percent rollout admits only 28 basis points of buckets.
Percentage rollout gate: Buckets are reduced into a thousand slots · case 01
Bucket values never exceed 999, so a 10 percent rollout enables every user.
Percentage rollout gate: Buckets are reduced into a thousand slots · case 02
Bucket values never exceed 999, so a 10 percent rollout enables every user.
Percentage rollout gate: Buckets are reduced into a thousand slots · case 03
Bucket values never exceed 999, so a 10 percent rollout enables every user.
Percentage rollout gate: Buckets are reduced into a thousand slots · case 04
Bucket values never exceed 999, so a 10 percent rollout enables every user.
Percentage rollout gate: Buckets are reduced into a thousand slots · case 05
Bucket values never exceed 999, so a 10 percent rollout enables every user.
Weighted variant allocation: Cumulative edges are treated as inclusive · case 01
A bucket equal to an arm boundary is assigned to the earlier arm, over-weighting it by one bucket.
Weighted variant allocation: Cumulative edges are treated as inclusive · case 02
A bucket equal to an arm boundary is assigned to the earlier arm, over-weighting it by one bucket.
Weighted variant allocation: Cumulative edges are treated as inclusive · case 03
A bucket equal to an arm boundary is assigned to the earlier arm, over-weighting it by one bucket.
Weighted variant allocation: Cumulative edges are treated as inclusive · case 04
A bucket equal to an arm boundary is assigned to the earlier arm, over-weighting it by one bucket.
Weighted variant allocation: Cumulative edges are treated as inclusive · case 05
A bucket equal to an arm boundary is assigned to the earlier arm, over-weighting it by one bucket.
Weighted variant allocation: Zero-weight arms participate in allocation · case 01
A variant switched off with weight zero still receives remainder traffic, and negative weights shrink totals.
Weighted variant allocation: Zero-weight arms participate in allocation · case 02
A variant switched off with weight zero still receives remainder traffic, and negative weights shrink totals.
Weighted variant allocation: Zero-weight arms participate in allocation · case 03
A variant switched off with weight zero still receives remainder traffic, and negative weights shrink totals.
Weighted variant allocation: Zero-weight arms participate in allocation · case 04
A variant switched off with weight zero still receives remainder traffic, and negative weights shrink totals.
Weighted variant allocation: Zero-weight arms participate in allocation · case 05
A variant switched off with weight zero still receives remainder traffic, and negative weights shrink totals.
Weighted variant allocation: Buckets past the total receive no variant · case 01
When weights sum below 100 percent, users in the leftover buckets get no variant at all.
Weighted variant allocation: Buckets past the total receive no variant · case 02
When weights sum below 100 percent, users in the leftover buckets get no variant at all.
Weighted variant allocation: Buckets past the total receive no variant · case 03
When weights sum below 100 percent, users in the leftover buckets get no variant at all.
Weighted variant allocation: Buckets past the total receive no variant · case 04
When weights sum below 100 percent, users in the leftover buckets get no variant at all.
Weighted variant allocation: Buckets past the total receive no variant · case 05
When weights sum below 100 percent, users in the leftover buckets get no variant at all.
Weighted variant allocation: Variants are walked alphabetically · case 01
Renaming an arm silently moves which bucket ranges it owns.
Weighted variant allocation: Variants are walked alphabetically · case 02
Renaming an arm silently moves which bucket ranges it owns.
Weighted variant allocation: Variants are walked alphabetically · case 03
Renaming an arm silently moves which bucket ranges it owns.
Weighted variant allocation: Variants are walked alphabetically · case 04
Renaming an arm silently moves which bucket ranges it owns.
Weighted variant allocation: Variants are walked alphabetically · case 05
Renaming an arm silently moves which bucket ranges it owns.
Weighted variant allocation: Fractional weights are truncated to basis points · case 01
A 0.29 percent arm covers only 28 buckets and 33.33 percent splits leak buckets.
Weighted variant allocation: Fractional weights are truncated to basis points · case 02
A 0.29 percent arm covers only 28 buckets and 33.33 percent splits leak buckets.
Weighted variant allocation: Fractional weights are truncated to basis points · case 03
A 0.29 percent arm covers only 28 buckets and 33.33 percent splits leak buckets.
Weighted variant allocation: Fractional weights are truncated to basis points · case 04
A 0.29 percent arm covers only 28 buckets and 33.33 percent splits leak buckets.
Weighted variant allocation: Fractional weights are truncated to basis points · case 05
A 0.29 percent arm covers only 28 buckets and 33.33 percent splits leak buckets.
Flag targeting precedence: Rules are evaluated before individual targets · case 01
A QA engineer added to an individual target list still receives the variation of a broad rule.
Flag targeting precedence: Rules are evaluated before individual targets · case 02
A QA engineer added to an individual target list still receives the variation of a broad rule.
Flag targeting precedence: Rules are evaluated before individual targets · case 03
A QA engineer added to an individual target list still receives the variation of a broad rule.
Flag targeting precedence: Rules are evaluated before individual targets · case 04
A QA engineer added to an individual target list still receives the variation of a broad rule.
Flag targeting precedence: Rules are evaluated before individual targets · case 05
A QA engineer added to an individual target list still receives the variation of a broad rule.
Flag targeting precedence: Negated clauses match users lacking the attribute · case 01
Anonymous users without a plan attribute are served the "not pro" variation.
Flag targeting precedence: Negated clauses match users lacking the attribute · case 02
Anonymous users without a plan attribute are served the "not pro" variation.
Flag targeting precedence: Negated clauses match users lacking the attribute · case 03
Anonymous users without a plan attribute are served the "not pro" variation.
Flag targeting precedence: Negated clauses match users lacking the attribute · case 04
Anonymous users without a plan attribute are served the "not pro" variation.
Flag targeting precedence: Negated clauses match users lacking the attribute · case 05
Anonymous users without a plan attribute are served the "not pro" variation.
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 ↗