playwright: [Bug]: Completed test fails on tearing down "context"
Version
1.41.1
Steps to reproduce
Successful test fails in teardown
in afterAll only ws client disconnect presents ( which completes successfully )
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)
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.