A JMeter gate counting false rows in the JTL passes when the run produced no rows. How do you harden it?

## The shape of the bug The rule is right about the numerator and silent about the denominator. `errors / total <= 0.01` with `total == 0` either divides by zero or, in the shell, evaluates `0 -le 0` and passes. Every false-green story on this leaf is a variant of it: the run that failed every sample at least produced rows to count, but the run that produced **no** rows produced no evidence either, and an absence looks exactly like a clean result to a rule that only counts errors. ## Three JMeter behaviours that reach zero rows 1. **The results file may not exist.** `StandardJMeterEngine.run()` compiles the plan with `PreCompiler` inside a `try`; on a `RuntimeException` it logs `Error occurred compiling the tree:` and returns *before* notifying test listeners. `ResultCollector` opens its file in `testStarted`, which is therefore never called. The process still exits `0` and `-l` wrote nothing. 2. **A file can exist with no samples in it.** When the run does start, `ResultCollector.getFileWriter` writes the CSV header immediately, and `jmeter.save.saveservice.print_field_names` defaults to `true`. So an empty run leaves a file of exactly one line. `[ -s "$JTL" ]` passes on it, and `wc -l` returns 1, not 0. 3. **A file can be truncated.** The writer wraps a `BufferedOutputStream` and `jmeter.save.saveservice.autoflush` defaults to `false`. Kill the JVM — a job timeout, an OOM, a runner reclaim — and whatever was in the buffer is lost. The surviving rows are a *sample* of the run, and if the failures clustered late they are the rows you lost. ## The order the checks have to run in - **Artefact exists and is non-trivial.** Fail if the file is missing or empty; fail separately if it has no data rows, and say which, because the two mean different things to whoever reads the log. - **Sample count meets a floor.** The floor comes from the plan: threads times loops, or the rate times the duration. A run that produced a tenth of the expected samples did not pass, whatever its error ratio says. - **Then the error ratio.** Only now is the denominator meaningful. - **Resolve the column by name.** The JTL layout is property-driven, so `success` is only the eighth field under a default `jmeter.save.saveservice.*` configuration. Read the header line and find the index; a hard-coded `$8` breaks silently the day someone adds a column. - **Fail closed on the checker's own errors.** `set -euo pipefail`, and treat "no `success` column found" as a failure rather than as zero errors. A gate whose input went missing must go red. ## The parsing caveat `CSVSaveService` quotes any field containing the delimiter, so a URL with a comma in a query string or an assertion message containing one produces a quoted field that a plain `awk -F,` will split in the wrong place. That is tolerable for a smoke check on a plan you control, and not tolerable as a shared gate — use a real CSV reader, or set the delimiter to something the data cannot contain, once the rule is guarding more than one plan. ## What is still outside the JTL's reach A truncated file and a job that hit its wall-clock limit look similar from inside the results file, so keep the job's own timeout as a separate failure signal rather than inferring it from row counts. And decide explicitly what a sub-sample means to your ratio: embedded resources and transaction children can appear as rows, so filter by `label` if the rule is meant to be about named transactions rather than about every HTTP call the plan made.