skip to content

In a Newman run, what happens when `-n` asks for more iterations than the `-d` data file has rows?

level: middleimportance: must knowfreq 52%

answer

  1. The count and the file can disagree
  2. It neither wraps nor errors
  3. Something gets reused when rows run out
  4. The last row comes round again

basics

~10 s

Newman neither wraps nor fails: iterations past the data file's last row repeat that last row. A count smaller than the row count simply runs the leading rows and never reaches the rest.

solid answer

~40 s

`-n` (`--iteration-count`) and `-d` (`--iteration-data`) are two independent CLI flags: one states how many iterations to perform, the other supplies the rows. When they disagree, the count wins and the data is stretched or truncated to fit. If the count is **larger** than the number of rows, the run still performs every requested iteration, and each iteration past the last row gets **that last row again** — it does not wrap around to the first row and it does not error. If the count is **smaller**, only the leading rows execute and the remainder are never seen. With `-d` and no `-n`, the row count decides. The practical consequence is that a mismatch is silent: the run looks healthy while re-testing one record over and over.

code

bash · 1 line
bash
newman run orders.postman_collection.json -d customers.json -n 9

go deeper

for a junior

Know that the count flag and the data file are separate inputs and can disagree. Remember the headline: extra iterations repeat the last row rather than wrapping or failing.

for a middle

Explain both directions of the mismatch — a larger count repeats the final row, a smaller one leaves the tail of the file unrun — and say why neither produces a warning.

for a senior

Demonstrate the operational instinct: a suite that suddenly gained rows but kept a pinned count is losing coverage, and the fix is at the command line rather than patched around in scripts.

for a principal

Own the standard for how runs are configured across teams: which flags a pipeline template is allowed to hardcode, and how a suite proves it covered its data instead of merely finishing green.

## Two flags, two different jobs A data-driven run is configured by two CLI flags that do not check each other: - **`-d` / `--iteration-data`** supplies the rows. Each row becomes the `pm.iterationData` scope for one iteration. - **`-n` / `--iteration-count`** states how many iterations the run should perform. When you pass only `-d`, the count is taken from the file: one iteration per row, which is the case almost everybody wants. When you pass only `-n`, the collection simply repeats that many times with no row behind it, and `pm.iterationData` is empty. Passing both is where the interesting behaviour lives, because the two numbers can disagree and **nothing warns you when they do**. ## When the count is larger than the file The measured behaviour is worth stating flatly: **a count past the data's last row repeats that last row.** The run performs every iteration you asked for; the rows are consumed in order until they run out; and from then on each remaining iteration is handed the final row again. Three things it specifically does **not** do: - It does not **wrap** back to the first row. There is no modulo over the data set, so you do not get a second lap. - It does not **error**. No exit is forced, no message stops the run, nothing marks those iterations as different. - It does not hand over an **empty** row. `pm.iterationData` still answers, with the last row's values, so scripts that guard on a missing column will not catch it either. That combination is what makes the mismatch dangerous rather than merely surprising. The extra iterations execute real requests and produce real results — they simply re-test one record. ## When the count is smaller than the file The truncating direction is the tamer one, and it is also silent. The run performs the count you asked for, consuming rows from the top, and the rows after that point are never executed at all. Nothing reports that the tail of the file went unused, which is why a count left over from debugging ("just run the first few") can quietly amputate coverage long after the debugging session ended. | flags | iterations performed | rows used | risk | |---|---|---|---| | `-d rows.csv` | one per row | all of them | none; this is the intended shape | | `-d rows.csv -n <fewer>` | the count | the leading rows only | coverage silently truncated | | `-d rows.csv -n <more>` | the count | all rows, last one repeated | coverage silently inflated | | `-n <count>` alone | the count | none; the scope is empty | the same request repeated, by design | ## Why repeating is the sensible default The count is a property of the **run**, and the file is a property of the **data**. The runner is asked to perform a given number of iterations and it does exactly that; having no further row to hand over, it re-supplies the one it has rather than inventing an empty record or aborting a run the operator explicitly requested. Wrapping would be a different and equally defensible choice, but it is not the one implemented, and confidently asserting a wrap is the classic wrong answer to this question. ## Keeping the two in step 1. **Do not pass `-n` at all when you pass `-d`.** Let the row count govern, and the two can never disagree. 2. Keep `-n` for the case it is actually for: repeating a run that has **no** data file, for instance to shake out flakiness in the same request. 3. If a pipeline template hardcodes a count, treat it as a defect the first time a row is added to the file, because the new row will not run. 4. If you truly need both, have the run assert its own shape — compare `pm.info.iterationCount` against a count the data itself carries, and fail loudly rather than repeating quietly. ## What a script sees during the repeats Nothing distinguishes a repeated iteration from a first-time one at the row level: `pm.iterationData` answers with the last row's values as normal. The only signal available in-script is positional — `pm.info.iteration` keeps advancing and `pm.info.iterationCount` reports the requested total, so a script can tell it is past the point where the file could still have new records only if it independently knows how many rows there were. That asymmetry is exactly why the fix is at the command line, not in the scripts.

  • How would you make a repeated last row visible instead of silent?
    Log the row alongside the position each iteration, so two identical rows at different positions are obvious in the output. Better, put a per-row identifier in the file and assert it differs from the previously seen one; that turns a quiet repeat into a named failure. Best of all, drop `-n` so the row count governs and the situation cannot arise.
  • When is passing an iteration count without a data file still the right thing to do?
    When repetition itself is the point: hammering the same request to expose flakiness, ordering effects, or state that leaks between passes. There is no per-row variation to supply, `pm.iterationData` is legitimately empty, and the count is the entire configuration. The trap is only in combining a count with a file whose length it contradicts.

saying these in an interview costs you the question

  • Claims the runner wraps back to the first row
  • Claims the run errors out when the count exceeds the rows
  • Thinks extra iterations get an empty row and skip harmlessly
  • Assumes the data file always overrides the requested count
  • Treats a green run as proof every row was executed