Document how to transfer cookies from setup() to all VUs

[leathej1]

If you use the setup function to perform login steps - for example, logging in and automatically storing an SSO cookie - those cookies that are stored will not be automatically available to the main function (please contact me for a specific reproduction, if needed).

[mstoykov]

Hm, I suppose we can make this work (haven't looked at the code) but I think it will be of little value. Ultimately you will probably have multiple logins in the majority of cases and you will need to return the tokens as an array/json object from setup() to somehow be used in the default function. You can see examples and more detailed explanation of this in the documenation, with the last two examples being the most releavant. you will probably run into setup timeout issues, and my post explains some workarounds for this.

I am not certain that having the cookies from the setup() cookiejar copied to all VUs is a good idea, @na-- ?

[na--]

We probably could implement something like this, but I don't think we should. Here are my two main reasons:

• It's not clear that using the setup() cookie jar as the starting point for all VUs is what all users would want. But if users want it, it's fairly easy to do so even now:

import http from "k6/http";

export function setup() {
    let res = http.get("https://httpbin.org/cookies/set?my_cookie=test&cookie2=123");
    return { cookies: http.cookieJar().cookiesForURL("https://httpbin.org") };
}

export default function (data) {
    if (__ITER === 0) { // or in initVU() after https://github.com/loadimpact/k6/issues/785 is done
        let jar = http.cookieJar();
        Object.keys(data.cookies).forEach(key => {
            jar.set("https://httpbin.org", key, data.cookies[key][0]);
        });
    }

    let res = http.get("https://httpbin.org/cookies");
    console.log(res.body);
}

• It will be a bit tricky to implement - setup() is executed in a different JS runtime (basically a transient VU) in local execution. With some effort. we could copy the cookie jar from that VU to all of the others, even though they're initialized before the setup() execution. But when there are multiple k6 instances, as is the case for the cloud execution and the planned native k6 distributed execution, setup() could be executed on a totally different machine. I'd like to minimize the amount of stuff we have to synchronize in that use case, and we're already syncing the returned data from setup...

What I propose instead of copying the cookies from setup() to all VUs is to better document that that's not the case, and also include the example of how it could be manually done in the docs. And, looking at the cookiejar API, we probably should improve that as well, since it's fairly unfriendly and lacking in functionality...

[leathej1]

Understood. I think I was assuming the cookie would be maintained, since most other performance tools have the same setup functionality, and it is used primarily as a login function.

[na--]

Moving this to the k6.io/docs repo, we should add something like the example above (#199 (comment)) to the docs, along with the explanation that setup() runs on a different runtime from VUs (and maybe even a different machine in cloud tests)