Collection-run classification for aborted requests: failure, skip, or retry?

Direct answer

In a Postman collection run with retry enabled, both a user‑cancelled request and a request that exceeds its timeout are treated as failures. The runner will retry the request up to the configured retry limit; only after all retries are exhausted does it increment the failure count. There is no built‑in way to classify such aborts as “skipped” or to change this behavior without modifying the request script.

Confirmed facts (based on current Postman/Newman behavior)

• Aborted or timed‑out requests are recorded as errors/failures in the run summary; they are never counted as skipped items.
• When retries are enabled, the runner automatically re‑issues the request after each abort, up to the retry limit, before marking the final attempt as failed.
• No per‑collection or per‑request setting exists in the Postman UI or Newman CLI to change the classification of aborts to “skip” or to suppress retries.
• Newman provides retry‑related options (e.g., --retry, --retry-delay) but no dedicated flag to override how cancelled versus timed‑out requests affect pass/fail totals.

Likely explanation

The collection runner treats any non‑successful outcome (including network errors, timeouts, and user cancellations) as an error condition. Its retry logic is applied to all error conditions before a final verdict is reached, and the summary aggregates only the final outcome (pass/fail). Because the runner does not expose a “skip” category for aborts, the only way to alter the counting is to intervene in the request script (e.g., by calling postman.setNextRequest(null) or by suppressing the error).

Verification steps (safe, scoped)

1. Postman Desktop/Web: Open a collection, enable retries (e.g., 2), manually cancel one request during a run, then view the run summary. Observe that the cancelled request appears under “Failed tests” and that the total failure count reflects the cancelled request after retries are exhausted.
2. Newman CLI: Run newman run collection.json --retry 2 --timeout-request 500 (or force a timeout with a delay endpoint). After execution, check the JSON or CLI output for the “failed” count; it should include the timed‑out request.
3. Inspect error shape (optional): Add a temporary test script: if (!pm.response) { console.log('Abort/error', pm.error); }. Run the collection in your client and note the logged object; this confirms the error object varies across desktop, web, and Newman.

Missing diagnostic detail

If you are using a specific version of Postman Desktop, Web, or Newman, the exact error‑object fields may differ, which could affect any script‑based workaround. Please confirm the client version you are targeting so that any script advice can be version‑specific.