Error: Context is done before all 'IterEnd' events were processed

Grafana k6 k6-browser
1

I am doing a POC for my team to try and implement K6 and looking to create a simple load of 10 VUs and 20 iterations i.e. 2 iterations per VU using ‘shared-iterations’ executor. But when I run it each time it runs approximately 15-18 users and ends with the warning error: Context is done before all ‘IterEnd’ events were processed

Version: k6 v0.46.0 (2023-08-14T13:23:26+0000/v0.46.0-0-gcbd9e9ad, go1.20.7, windows/amd64)

What I am interested to know is there are VUs available and maxTimeOut of 10mins is not reached but it still doesn’t run the iterations.

Note that the console doesn’t stop and kind of hangs there itself after this.

Am I missing something here?

import { browser } from 'k6/experimental/browser';
import { sleep, check } from 'k6';

export const options = {
    scenarios: {
        ui: {
            executor: 'shared-iterations',
            vus: 10,
            iterations: 20,
            options: {
                browser: {
                    type: 'chromium',
                },
            },
        },
    },
    thresholds: {
        checks: ["rate==1.0"]
    }
}

export default async function () {
    // const context = browser.newContext();
    console.log(browser.version());
    const page = browser.newPage({
        ignoreHTTPSErrors: true,
        }
    );

    try {
        /* Navigate to the url */
        await page.goto(URL);
        page.waitForTimeout(100);
        
        /* Login to the Web URL */
        const username = page.locator('[id="username"]');
        username.type('user1');
        const password = page.locator('[id="password"]');
        password.type('Abc@1234');
        
        const submitButton = page.locator('[id="loginFormUsernameAndPasswordButton"]');
        await Promise.all([page.waitForNavigation({
            timeout: 30000,
            waitUntil: 'domcontentloaded',
        }), submitButton.click(),]);
        page.waitForTimeout(1000);

        /* Click on My Account tab */
        const myAccountButton = page.locator('//button[contains(@id,\'myAccount\')]/span[contains(text(),\'MyAccount\')]');
        await Promise.all([myAccountButton.click(),]);
        // sleep(10);

        /* Click on Account Settings tab that appears on clicking My Account tab*/
        const accountSettingsButton = page.locator('//*[@id=\'myAccount_1077722406\']/a[1]');
        await Promise.all([page.waitForNavigation(), accountSettingsButton.click(),]);
        
        check(page, {
            'Account Page URL': p => p.url().match(/.*account/),
        });


    } finally {
        page.close();
    }
}
3

Hi @anilkothacheruvu,

But when I run it each time it runs approximately 15-18 users

What do you mean by this? I’ve ran some tests and when working with the shared-iterations executor where the vu count is 10 and iteration count is 20, I can see that 10 vus are running and working through the iterations. It’s not guaranteed that all the vus will each run through 2 iterations each. One vu could complete 1 or more than 2.

I’m unable to reproduce this issue. Any chance of you being able to recreate this on a public facing website?

Could you also provide the full output of the test?

What happens when you let the test run until the max duration of 10 minutes?

Cheers,
Ankur

5

I think I might have just bumped into the same issue running non-browser load tests. I’m pretty sure it is because the O/S is out of memory or file handles. I was running some load tests gradually building up the number of VUs. As soon as it hits around 60 it goes bang with that error repeatedly about 4 minutes into the test. All the VUs die and I can see “too many open files” errors along with it too.

8

Aha, that could also be the case for the thread starter since each vu essentially controls its own instance of Chrome, and if the computer the test is running on doesn’t have enough compute resources then it could fail with unexpected errors.

When I’ve ran into similar issues, the browser module will spit out timeout errors where it’s tried to do some action but hasn’t been able to and eventually a timeout occurs. This can happen either when the browser module is overloaded, or when chrome it self is too busy.

1 Like
9

Yes, i’m running k6 in WSL Ubuntu on Windows - I ran up htop whilst it was ramping up yesterday and was quite shocked at the memory usage.

It’s worth checking out the latest version 0.49 as they have changed the browser stuff so that it doesn’t rely on waiting for elements for 30 seconds (and it has a very handy web console to watch your tests live.

1 Like