Init Code Support Get Requests

[coffeebe4code]

Feature Description

I'm sorry, but I disagree. I need to test an api's scaling, performance, and load test not the authorization server that generates a token. We write code and use libraries that do not make extra requests to the authorization server for a token, why should the load testing tool be any different

Init code should be able to get a token, set the value, and then my check function only checks every 4min~ or whatever the token lifetime is.

Suggested Solution (optional)

No response

Already existing or connected issues / PRs (optional)

No response

[na--]

You disagree with what? 😅 Did some of the feature description text go missing? I am confused exactly what you are describing here.

My best guess is that you'd like to be able to make HTTP requests (and, presumably, other network requests) in the VUs' init contexts? If so, there are reasons why that would cause problems, some of which I've previously described in other issues, e.g. #2719 (comment)

Can you elaborate more on your use case? And why setup() or VU code is insufficient to address it?

[jayson-panganiban]

Any workaround to this? My use case is I need to fetch data via http call and use that in my requests.

[na--]

@jsonpanganiban, can you answer the same question I asked @coffeebe4code - why is setup() insufficient for your needs? Any more details about the use case than "fetch data via http call and use that in my requests"? 😅

As you can see from the link I gave in my previous post, due to the architecture of k6 and what "VUs" actually are (JavaScript runtimes), we are supremely unlikely to ever allow HTTP requests in the "VU init" scope, which essentially is the global JS scope that gets executed every time a new VU's JS runtime is initialized. Having any sort of network code there will simply cause way more problems than it will solve.

However, I suspect that even if we did allow that, it won't actually solve your problems, it will just push them one level down, e.g. now VUs would be running out of memory, test init will be flaky or take ages, etc. I might be wrong though, so that is one reason to share details about your use cases and the problems you are hitting...

Another reason I am also trying to understand the details of what you are trying to do and what problems and limitations you are experiencing is because it will help me to offer viable workarounds for them, and it will help the k6 team to prioritize some of the actual issues that might solve them without any of the downsides of making network calls when initializing VUs. For example #2043, #1638, #785, #1342 (and probably others) are all open issues for potential solutions in that general area... These issues have their own implementation challenges, as you can see from the comments, but are still possible to implement without sacrificing a lot of stability.

To get back on topic, if you can use it, setup() is the easiest "workaround" for your problem, in the sense that it was kind of meant as the official solution for this... 😅 Unfortunately, it currently doesn't work very well with huge amounts of data, so we have #2043 open.

And, if that is indeed the k6 limitation you are experiencing, you may need to make these requests outside of k6 and e.g. save the responses in a .json file for k6 to open() and put in a SharedArray 😞 Alternatively, you can make these requests in one k6 scenario, save the responses in a Redis instance or some such, and then use that in another scenario. Another alternative is to write an xk6 extension. There may also be other options, but I don't know enough about what you are trying to do to offer them...

[coffeebe4code]

I think I misunderstood, init seemed like the most global scope you had, but the setup() might work. I ended up passing the data into k6 as an environment variable, this making it truly global or once.