Scenario's stage number

[codebien]

Adding scenario's stage id information.
Export the property exec.scenario.stage.id that returns a zero-based value tracking for the current running stage.

An example using it for tracking the stage as a tag:

import http from 'k6/http';
import exec from 'k6/execution';

export const options = {
  stages: [
    { duration: '1m', target: 10 },
    { duration: '1m', target: 20 },
    { duration: '1m', target: 0 },
  ],
};

export default function () {
  exec.vu.tags["stage"] = 'stage#${exec.scenario.stage.id}'
  http.get('http://test.k6.io/');
}

[mstoykov]

I don't think trying to calculate the exact stage you are in based on time every time exec.scenario.stage.number is accessed is a good idea at all.

As I've mentioned I doubt most users will care about that, they probably just want in which stage it started. On the other hand (as I mentioned inline) this will IMO be really confusing when it starts changing values and will lead to really hard to understand bugs.

This also is somewhat less logical for an iteration based executor such as ramping-arrival-rate as that iteration started in the "ramping-up" part , the fact that the executor is now in the "ramping-down" (after 10 minutes of "steady" stage) is probably interesting, but I would argue that this iteration is still from "ramping-up" stage ;) . With ramping-vus I would argue the opposite is more coherent. Maybe we should have exec.iteration.stage and exec.scenario.stage 🤷

I am also not really certain about the whole name stuff ... and at this point I feel like maybe we should scrap all this and just have per stage tags and env variables as we have per scenario and call it a day 🤷.

[mstoykov]

nit: you can just make with the appropriate len(instead of cap) and do stages[i] = ... instead of append

[mstoykov]

This is going to throw an exception on executors with no stages? I am not certain this is the best idea instead of returning undefined for example, but 🤷 works as well.

[mstoykov]

I don't really think that trying to calculate the exact stage on each call is a good idea. I really don't think that will be what most users will care about and if they do there is an easy way to do it (as you do here).

But I would expect it will be really surprising to people accessing exec.scenario.stage.number in two different parts of their iteration and it ... changing.

I do expect that later one will definitely get them to scratch their head quite a bit and try to figure out how did they write their code in such a way that a key they just added with exec.scenario.stage.number is now not there 🤔

[codebien]

I am also not really certain about the whole name stuff ... and at this point I feel like maybe we should scrap all this and just have per stage tags and env variables as we have per scenario and call it a day shrug.

@mstoykov The main problem with this it's the ramping-vus executor, because we don't have a defined instant when the stage is changing, so we can't set the tags for it. Am I missing something?

[na--]

@mstoykov we've had this discussion already, and the consensus (or so I thought) was that if we had this stage number, users will be able to cover every use case reasonably easily and logically:

• If you want to get which stage the iteration is in, query exec.scenario.stage.number at the start of the iteration and save the result in a variable.
• If you want to get which stage a particular HTTP request actually occurs in, query the stage.number before/after you make it.
• If you want extra tags, use exec.vu.tags to add them
• If you want extra env vars for different stages, you can have a map and use the stageNumber to look them up

Regarding the rest, I think we should hold off on stage.name... IIRC we haven't decided if that would automatically add tags or not yet. And stage.number should probably be renamed to stage.id to be consistent with the rest of the k6/execution properties 🤔

[codebien]

Updated the description adding a small example, I will remove the name property.

[mstoykov]

@na-- I am very much against exec.scenario.stage.number==exec.scenario.stage.number being able to return false.

I do think this will be way more confusing and add bugs than if exec.scenario.stage.number is just a constant.

All of the above other usecases, which I doubt are all that interesting for most users - I would expect most just want to know "vaguely" whether this iteration started in a given stage, after all as you've eluded that will change and it can change also over the course of a request, and we are not even doing asynchronous code yet. But I digress ... all of the above other usecases can be handled through js code, which is already possible as @codebien has shown. And as I have argued time and time again, adding functionality that can be implemented outside of k6 means that we still have to document it(which we have to do for the js code as well), but now we also can't change it, while we can always release another jslib showing how to use something else but as v0.2.0 ;)

If anything in order to make it easier I am more for exec.scenario.stages being a "copy" of what the stages in the configuration for the given scenario are. This is unlikely to have to change and will be helpful for implementing the above use case as well as anything else.

Also again, can we discuss API changes with examples in the issues at least along implementing them if not before that?

[na--]

I moved the milestone for this to v0.36.0. I disagree with you and think something like this is probably the best solution, but let's discuss it in #2215 after we ship v0.35.0...

[codebien]

This isn't in the current plan, we could reconsider this in the future but at the moment is not going to be merged. For the current plan check: #796 (comment)