shared-iterations __ITER variable executed by multiple VUs concurrently

[liugang585570]

Brief summary

Problem Description When using the shared-iterations executor in k6, the __ITER variable, which is documented to represent a unique global iteration ID (0 to iterations - 1), is observed to be executed by multiple Virtual Users (__VU) simultaneously. This contradicts the expected behavior of shared-iterations, where each global iteration should be processed exactly once by a single VU.

This leads to unintended duplication of requests when the script relies on __ITER to access a unique element from a shared data array (e.g., requests[__ITER]), as multiple VUs end up processing the same index.

k6 version

k6 v1.0.0 (commit/41b4984b75, go1.24.2, linux/amd64)

OS

Alibaba Group Enterprise Linux Server 7.2 (Paladin)

Docker version and image (if applicable)

No response

Steps to reproduce the problem

Create a k6 script named test.js with the following content:

javascript // test.js import http from 'k6/http'; import { sleep } from 'k6';

export let options = { scenarios: { test_scenario: { executor: 'shared-iterations', vus: 5, // Small number of VUs for easy observation iterations: 10, // Small number of iterations maxDuration: '1m', }, }, };

export default function () { console.log([DEBUG_SIMPLE] VU: ${__VU}, ITER: ${__ITER}); // Send a simple HTTP request to ensure the default function runs and is not optimized away http.get('http://test.k6.io'); sleep(0.01); // A small sleep to give time for logs to be flushed and make concurrency more apparent } Run the script from your terminal:

bash k6 run test.js Observe the console output.

Expected behaviour

Each __ITER value (from 0 to 9) should appear exactly once in the console output, associated with a single __VU. The specific VU assigned to each __ITER is determined by k6's scheduler, but there should be no duplicate __ITER entries across different VUs.

For example, a normal output might look like (order may vary):

INFO[0000] [DEBUG_SIMPLE] VU: 1, ITER: 0 source=console INFO[0000] [DEBUG_SIMPLE] VU: 2, ITER: 1 source=console INFO[0000] [DEBUG_SIMPLE] VU: 3, ITER: 2 source=console INFO[0000] [DEBUG_SIMPLE] VU: 4, ITER: 3 source=console INFO[0000] [DEBUG_SIMPLE] VU: 5, ITER: 4 source=console INFO[0001] [DEBUG_SIMPLE] VU: 1, ITER: 5 source=console INFO[0001] [DEBUG_SIMPLE] VU: 2, ITER: 6 source=console INFO[0001] [DEBUG_SIMPLE] VU: 3, ITER: 7 source=console INFO[0001] [DEBUG_SIMPLE] VU: 4, ITER: 8 source=console INFO[0001] [DEBUG_SIMPLE] VU: 5, ITER: 9 source=console

Actual behaviour

The log output shows that the same __ITER value (e.g., ITER: 0) is being executed by multiple VUs concurrently. All VUs report processing ITER: 0 (and potentially other ITER values) at the exact same timestamp.

Example from my test run:

INFO[0000] [DEBUG_SIMPLE] VU: 2, ITER: 0 source=console INFO[0000] [DEBUG_SIMPLE] VU: 1, ITER: 0 source=console INFO[0000] [DEBUG_SIMPLE] VU: 3, ITER: 0 source=console INFO[0000] [DEBUG_SIMPLE] VU: 5, ITER: 0 source=console INFO[0000] [DEBUG_SIMPLE] VU: 4, ITER: 0 source=console INFO[0001] [DEBUG_SIMPLE] VU: 3, ITER: 1 source=console INFO[0001] [DEBUG_SIMPLE] VU: 4, ITER: 1 source=console INFO[0001] [DEBUG_SIMPLE] VU: 2, ITER: 1 source=console INFO[0001] [DEBUG_SIMPLE] VU: 5, ITER: 1 source=console INFO[0001] [DEBUG_SIMPLE] VU: 3, ITER: 2 source=console In this snippet, all 5 VUs (1, 2, 3, 4, 5) reported ITER: 0 at the same [0000] timestamp. This indicates a fundamental issue with how shared-iterations are distributed among VUs. If this __ITER was used as an index for an array data[__ITER], then data[0] would effectively be processed 5 times.