Input Reduction on Selectivity.net

Selectivity Keeps a Useful Checkpoint When the Test Budget Runs Out

Sat, 24 Oct 2026 00:00:00 +0000

A reduction can be useful before it is finished. That matters when the predicate is expensive, a CI job has a fixed allowance, or a developer wants to make a first pass without committing to thousands of executions. Selectivity’s execution budget puts a bound on how many predicate processes can start. Reaching that limit leaves an incomplete run and the latest accepted checkpoint, rather than silently promoting unfinished work to a completed result.

Selectivity Makes Large Bug Reports Easier to Understand

Sat, 24 Oct 2026 00:00:00 +0000

A minimal reproducer is a small example that still demonstrates a problem. It gives the person investigating a bug less material to read and fewer irrelevant details to carry through each experiment. Getting there is often laborious. You remove a group of rows, rerun the program, discover that the failure has vanished, restore the rows and try a smaller group. It is useful work, just rather repetitive.

Selectivity turns that routine into a search driven by a predicate. The predicate is a command that answers whether the particular behavior survives in the candidate input. Selectivity begins with larger deletions and works toward smaller ones when necessary. Each successful deletion becomes the new starting point. Eventually the engine reaches individual units, such as one line or one file, and checks whether removing any of them still preserves the predicate.

Selectivity Reduces Failing Inputs and Records Every Candidate Check

Sat, 24 Oct 2026 00:00:00 +0000

A useful bug report often begins with an unhelpfully large attachment. The program fails on a particular export, configuration bundle or text file, but nobody knows which part matters. Selectivity automates the patient part of that investigation: remove some material, run a command that recognizes the target behavior, and keep the smaller input when the same behavior survives. The first release handles lines in a file and whole files in a directory, with an optional pass over the lines inside the remaining files.

Selectivity Takes Its Name From the Rule That Chooses What Survives

Sat, 24 Oct 2026 00:00:00 +0000

Selectivity is named for the decision at the center of every reduction. Some parts of an input are necessary to preserve the behavior under investigation. Other parts can disappear. The engine discovers useful deletions by applying a rule supplied by the developer, over and over, to progressively smaller candidates.

That rule is the predicate. It might recognize a specific crash, a disagreement between two parsers or a configuration combination that produces the wrong result. The same input can reduce differently under a different predicate, because a different question makes different material relevant. The name points to that dependence. Selectivity chooses what survives according to an explicit test.

Selectivity Tests Input Preservation and Uncertain Predicates

Sat, 24 Oct 2026 00:00:00 +0000

The central promise of a reducer is easy to state and surprisingly easy to weaken: the saved input should be smaller, while still satisfying the behavior being investigated. Testing only a successful reduction would miss several ways that promise can go wrong. Selectivity’s verification therefore checks the copies and the evidence around the search, alongside the search itself.

The automated tests cover line reduction, directory file removal and the optional line pass inside directory files. They also check empty input, raw line-ending preservation and files without a final newline. One predicate deliberately overwrites its disposable input. The saved result must still contain the accepted snapshot bytes, and the source must retain its original contents. A permissions test uses a restrictive creation mask to confirm that the copy restores the modeled file permissions explicitly.