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

[scriptonist]

The Change

The commit e2669d38 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 455b3088). 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