What does `go test`'s `-fuzzminimizetime` flag control when a fuzz target hits a failing input?

### Minimization: the step between "found a crash" and "saved a file" Coverage-guided fuzzing finds failures by mutating inputs, so the input that finally breaks a binary frame parser is usually mostly irrelevant. It may be kilobytes long, with one malformed length prefix buried inside a mass of bytes that had nothing to do with the bug. Handing that to a reviewer is close to useless. So before writing anything to disk, the engine tries to **minimize**: it constructs smaller and simpler candidates derived from the failing input, runs the target on each, and keeps any candidate that still fails. The result is a much smaller input that triggers the same code path. That minimized input is what gets written to `testdata/fuzz/<FuzzName>/<hash>`, and it is what you review and commit. ### What the flag actually bounds `-fuzzminimizetime` sets the budget for each minimization attempt. Two forms are accepted: - a duration, for example `-fuzzminimizetime=10s` or `-fuzzminimizetime=2m`; - an iteration count using the `Nx` syntax, for example `-fuzzminimizetime=100x`, meaning run the target that many times during the attempt. The default is `60s`. The budget is per minimization attempt, not for the fuzzing session as a whole - the session's own budget is a separate flag entirely, and confusing the two is the most common mistake with this option. When the budget expires, the engine stops shrinking and saves whatever it had reached. Nothing is lost by a small budget except size: you still get a genuine failing input, just a less tidy one. ### Choosing a value - **Interactive debugging on a laptop.** Lower it. You mostly want the crash file to exist so you can start iterating with `go test -run='FuzzParseFrame/<hash>'`; a slightly bulky input is fine, and waiting a minute per failure is annoying when you are hunting several. - **A scheduled or overnight run whose output a human reads in the morning.** Leave the default, or raise it. Nobody is waiting, and a smaller entry means a clearer bug report, a cheaper committed regression test and a diff that reviews easily. - **A target that is expensive per call.** Minimization is just repeated target invocations, so if a single parse takes milliseconds, a 60s budget buys far fewer shrink attempts than it does on a microsecond-scale parser. Think in iterations, not seconds; that is exactly what the `Nx` form is for. ### The determinism caveat Minimization rests on an assumption: running the target on the same input gives the same verdict. If the target is non-deterministic - it keeps state between calls, depends on map iteration order, involves timing, or touches shared globals - that assumption breaks. The engine can then shrink into an input that fails for a different reason, or produce one that does not reliably fail at all. The symptom is unmistakable and worth recognising: the saved corpus entry reproduces the panic only sometimes. When that happens the corpus entry is not the problem; the target is. Make the fuzz target a pure function of its arguments - construct fresh state inside it, avoid globals, avoid wall-clock dependence - and re-run. Only then is the minimized entry worth committing, because only then will it be a stable regression test for everyone else who runs `go test`. ### Why this matters for what you commit Everything about the committed corpus argues for small entries. A minimized input is faster to run on every build, easier to review, easier to reason about when it fails again in two years, and less likely to be an unnecessarily rich piece of attack material if the repository is public. Minimization is the step that produces that quality, and `-fuzzminimizetime` is the dial that decides how much you pay for it.