Seeing the ReferenceError: __ITER is not defined for execution context variables.

[ahmetoz]

Environment

• k6 version: k6 v0.33.0 (2021-06-29T10:38:31+0000/cc0361c, go1.16.5, linux/amd64)

Expected Behavior

__ITER should be defined. But code throws ReferenceError: __ITER is not defined, This is happening when we install the k6 to a linux server, same code runs as expected in local machine with different k6 version (k6 v0.29.0 ((devel), go1.15.5, darwin/amd64))

Actual Behavior

__ITER should be defined as __VU, the code is called in a setup context with a code added as local file system module. When I log the execution variables, I could see the __VU set to 0 but __ITER is undefined.

Steps to Reproduce the Problem

My assumption is sth changed in latest release.

[na--]

Thank for reporting this, I can reproduce it with the following simple script:

export function setup() {
    console.log("setup(): ", __VU, __ITER);
}

export default function () {
}

It "works" in k6 v0.32.0, but returns ReferenceError: __ITER is not defined on v0.33.0. I assume we probably "broke" it in some of the refactoring around the k6/execution module (#1863).

I am putting "works" and "broke" in quotes because I am not sure if I should treat this as a bug 😕 __ITER has never worked in the init context, and continues to work fine in the VU context even in k6 v0.33.0. setup() and teardown() are somewhere in-between, though they are probably closer to the init context. It doesn't really make sense to use __ITER in them, even when it "worked", it was always going to have 0 as its value, since you don't really have iterations in setup() and teardown().

If anything, the fact that we had __ITER in setup() and teardown() before might be considered a bigger bug than us removing it 🤷‍♂️ 😅 But in any case, we didn't realize we had removed it, so at the very least, we should have mentioned it in the Breaking Changes section of the v0.33.0 release notes, even if it was previously undefined and unsupported behavior... 😞

Maybe I'm wrong about its utility though... @ahmetoz, can you explain what your use case for __ITER is here and why it's a problem that we broke it? Besides the obvious frustration of an unexpected breaking change, of course, for which I sincerely apologize... 😅 🙇

[ahmetoz]

No need to apologize 😄 Thanks for the explanation, thanks for supporting this great tool.

I'm using the __VU and __ITER context variables, to make correlation id header unique and traceable. Simply, in our backend logs, I could filter which VU runs which requests, similar to ITER like span ids to track which http requests run in this iteration.
The correlation id builder is a kind of utility that returns a string, I add also some other information to header but in general functionality is common for all http requests, you might be correct about the purpose of ITER in setup, we could create different header for context calls.

[na--]

Thanks for explaining, and you might want to also chime in #1320 with your use case. We're currently in the middle of implementing the first version of that new execution API that will return much richer execution information than just __VU and __ITER. It is also primarily meant for the VU context, since that's when users usually want the information, but with enough valid use cases we might build something useful for the init context and/or setup() and teardown() next.