playwright: [Bug]: Completed test fails on tearing down "context"

Version

1.41.1

Steps to reproduce

Successful test fails in teardown Screenshot 2024-02-09 at 11 07 25

in afterAll only ws client disconnect presents ( which completes successfully ) Screenshot 2024-02-09 at 11 21 25

Similar https://github.com/microsoft/playwright/issues/24210 - but there were failing test so trace: 'retain-on-failure', shouldn’t bother

const config: PlaywrightTestConfig = {
    globalSetup: require.resolve("./global-setup"),
    use: {
        // headless: false,
        ignoreHTTPSErrors: true,
        screenshot: "off",
        video: "off",
        trace: "retain-on-failure",
    },

    projects: [
        {
            name: "Desktop-Chrome",
            use: {
                browserName: "chromium",
                channel: "chrome",
                viewport: { width: 1920, height: 1080 },
                launchOptions: {
                    args: ["--disable-web-security"],
                    // slowMo: 1000,
                },
            },
        },
    ],
    expect: {
        timeout: 15000,
    },
    reporter: [["list"], ["html", { open: "never" }], ["./customReporter.ts"]],
    reportSlowTests: { max: 0, threshold: 240000 },
    timeout: 230000,
    globalTimeout: 2500000,
    forbidOnly: !!env.CI,
}

Expected behavior

tests not failing on standard fixtures teardown

Actual behavior

Test finished within timeout of 230000ms, but tearing down "context" ran out of time.
Please allow more time for the test, since teardown is attributed towards the test timeout budget.

from the test steps seen, there was plenty of time for teardown 😦 happens rarely, but brings frustration

Additional context

No response

Environment

gitlab CI 
+
FROM mcr.microsoft.com/playwright:v1.41.1-jammy
+
ARG CHROME_VERSION="121.0.6167.85-1"

About this issue

  • Original URL
  • State: closed
  • Created 5 months ago
  • Reactions: 7
  • Comments: 16 (5 by maintainers)

Most upvoted comments

We are encountering the same issue. Sometimes the teardown of a test takes an unexpectedly long time

Same here. It would be great if I don’t have to use ‘on-first-retry’ - retries sweep bugs under the rug. Sometimes there are bugs caused by race conditions - e.g. one request happens to arrive before the other and then it reproduces. I want to catch them and that trace is a mighty tool!

@dimkin-eu I think this is still related to tracing. Even though there were no errors, the trace was still recorded (just in case there would be a failure), and tracing is stopped during the teardown. Let me think what we can do about it. From the timing on your screenshot, it looks like teardown takes the vast majority of the execution time, so increasing the timeout is unlikely to help.