k6/execution: add more information about the current VU

[na--]

This is a continuation of some of the things mentioned in #1320 that relate to information about the current VU, but which were not implemented in the original k6/execution API that shipped in k6 v0.34.0.

We already offer quite a lot of information through k6/execution.vu, but we don't have these:

• the current group name / path - group() calls can be nested arbitrarily deeply, and when we couple them with some code reuse functions, it might be useful to be able to programmatically get what is the current group. This might become even more relevant if we enhance what group() can do by implementing Ideas for improving the group() built-in function #884 or something similar...
• idInScenario - the ID of the current VU in the current scenario. Since VUs are initialized concurrently after New executors #1007, and since VUs can be reused across scenarios, the current vu.idInInstance and vu.idInTest identifiers are quite jumbled and unsuitable for anything besides partitioning data. This local ID for every scenario could be useful, especially in executors like ramping-vus where VUs are very ordered and lower-numbered VUs will always be started first and stopped last.

[na--]

A way to atomically query the current BytesWritten and BytesRead (i.e. the values that are emitted as data_sent and data_received at the end of the iteration) from the global per-VU Dialer also makes some sense to be added to the execution.vu capabilities, see #2283 (comment) for details. #1250 should maybe also be implemented at the same time 🤷‍♂️

[amommersteeg-d2l]

Hello I am interested in the idInScenario feature suggested above, has there been any progress?

For our use case we have a test that requires unique data read from an array, we were using the vu.idInInstance as the index for that array. But when this test runs with other tests as a scenario the vu.idInInstance can start to be larger than the length of the array.

[na--]

@amommersteeg-d2l, there hasn't been any progress here because this issue hasn't been very highly prioritized so far. Thanks for sharing your use case, that helps us to prioritize more accurately and understand what we should build. Please also upvote (:+1:) the issue itself.

Unfortunately, if I understand your use case correctly, I don't think there is a workaround you could use before this is implemented... 😞 Test suites (#1342) or a dedicated data segmentation API (#1539) might have offered an alternative, if they were implemented, but they are unlikely to be done any time soon.

What is the executor type of your scenario and what does the scenario test? Do you need to always pin the unique data entry per every VU in the scenario? Because if you can change the test to get a unique row on every iteration, then scenario.iterationInTest from k6/execution might be a viable alternative?

[amommersteeg-d2l]

@na-- yeah, it looks like you understand the use case correctly. We are using the scenarios in a new script were we import individual tests, so a test suite. It allows use to run a nightly test without having to completely rewrite the individual tests. For some tests we can't have the same user completing the action at the same time, it will case the test to be flaky.

Thank you for the idea of using scenario.iterationInTest, that would get us unique index that we need. It could be valid option for us since with nightly tests we really restrict things (environment resources, test time, etc.).

The other option we are looking it is using https://github.com/grafana/xk6-exec to help get unique indexes of a VU from a separate script and file while the VU is being initialized. (Have tested yet, so not sure of the time impact).

[na--]

I'm happy that scenario.iterationInTest will help you in the short term, though vu.idInScenario also has valid use cases and will probably be added sooner or later. Also keep an eye at #1342. It is not under active development, but I recently made a very simplistic proof-of-concept implementation of parts of it in #2816, to gauge what the blockers before it are, and that was successful 🎉

While it's highly unlikely we'd even start properly working on it in the next 6 months (:disappointed:), when it is done, it may be a much nicer solution for your use case (and similar ones) than trying to abuse scenarios and complicated k6/execution options 🤞 😅