Passing data from `setup` to initVU stage

Grafana k6 OSS Support
1

I’d like to be able to use data returned from setup in the init stage.

// Global setup
export function setup() {
  return ["some_data"]
}

// InitVU
const myObject = data // data from setup

export default function() {
  // use myObject
}

Based on the docs, it seems like this is currently not possible. It’s my understanding that setup will be run on a separate VM so the data returned from it must be JSON serializable. As long as that’s true, is there anything preventing us from accessing data in the init stage vs. the VU stage?

1 Like
2

Hi @vishalkuo,

You can not use the setup data in the init context … Maybe technically we can make that work, but it is currently not possible and is unlikely to ever be done.

As a workaround you can just have

export default function(data) {
  if (__ITER==0) {
    // what you want to do in the init context with the `data`
  }
  // the rest of your code
}

If all you want to do is set myObject to data … that is fine, but also totally unnecessary as data will be provided either way on each call to default :slight_smile:

3

Yeah, unfortunately I forgot to mention I’m doing a little more with data than the example showed, it’s more like

// InitVU
const myObject = longInitFunction(data)

I can certainly use the __ITER method; however, as noted in this issue - this skews the first iteration duration. I wanted to see if I could avoid this, but I can probably make it work for now.

4

Yeah it would’ve been nice if there is a workaround, but I am not aware of one, and getting the data available in the init context might be a bit on the hard side, even if we decide to do it :frowning:

this skews the first iteration duration

I have argued this other times, but for the typical load test that I have seen (multiple minutes sometimes upwards of an hour, with (hundreds of) thousands of iterations) the fact the first iteration is a bit longer is usually not a problem, the skewing on the avg will be minimal and the only ones that will suffer significantly will be max which will be totally wrong and p(99999) or something like that. It is far from perfect, but I am pretty sure that the actual skewing for the majority of the cases will be close to 0 ;).

As a workaround(we always have those :tada: ), you can have:

export default function(data) {
  if (__ITER==0) {
    // what you want to do in the init context with the `data`
  }
  group("actual iteration", function() {
    // the rest of your code
  })
}

And then instead of using the iteration_duration you can use the group_duration for “actual iteration” (please change the name though :slight_smile: ).