fix(nested-requests): disable parallel iterations for nested runners

[scriptonist]

The Change

The commit e2669d3 adds a single line in lib/runner/nested-request.js:133:

customParallelIterations: false

This option is passed when creating a new runner for nested requests (requests invoked via pm.execution.runRequest()).

Background Context

1. Parallel Iterations Feature
   The runtime recently added support for running collection iterations in parallel (commit 455b308). This feature allows multiple iterations to execute concurrently, controlled by options like:

• maxConcurrency - number of parallel iterations
• customParallelIterations - flag to enable custom parallel iteration management

When enabled (areIterationsParallelized = true), the runtime:

• Creates a PartitionManager to divide iterations across "partitions"
• Uses the parallel.command.js extension instead of waterfall.command.js
• Manages complex coordination between concurrent iteration execution

2. Nested Requests
   When a script calls pm.execution.runRequest(), the runtime creates a new independent runner to execute the referenced request. This nested runner is created at line 114 in nested-request.js.

The Problem

Without this fix, when creating a nested runner, it would inherit all options from the parent runner, including parallel iteration settings. This caused issues:

1. Unnecessary Complexity: Nested requests typically execute once (not in iterations). They don't need parallel execution infrastructure.
2. Configuration Conflicts: Looking at run.js:112-115, when customParallelIterations is enabled:
   if (this.options.customParallelIterations) {
   this.options.maxConcurrency = 1;
   this.options.iterationCount = 1;
   }
3. The nested runner would go through this logic even though it's explicitly configured with iterationCount: 1 (line 122).
4. Resource Overhead: The nested runner would unnecessarily:
   - Spawn a partition manager
   - Create partitions for a single iteration
   - Use parallel command processing infrastructure
5. Potential Execution Issues: Nested parallel execution could lead to unexpected behavior in:
   - Event triggering (abort, iteration lifecycle)
   - Variable scope management
   - Cursor tracking across nested parallel contexts

The Solution

By explicitly setting customParallelIterations: false, the nested runner:

• Always uses sequential execution (waterfall.command.js) regardless of parent configuration
• Skips parallel iteration infrastructure (partition manager, parallel processing)
• Maintains simpler execution semantics appropriate for single-request invocation
• Prevents configuration inheritance issues from parallel-enabled parent runners

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 41.92%. Comparing base (40ef304) to head (e248ac5).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #1536   +/-   ##
========================================
  Coverage    41.92%   41.92%           
========================================
  Files           49       49           
  Lines         3790     3790           
  Branches      1085     1085           
========================================
  Hits          1589     1589           
  Misses        2078     2078           
  Partials       123      123           

Flag	Coverage Δ
unit	41.92% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.