For the main issue, I suggest you look through https://playwright.dev/docs/debug to try to attach a debugger and step through what is happening. That will probably give you a good idea of what is hanging.

The --ui crash is due to having DEBUG flags set. This is something we should fix.

@agg23 debug is not helpful because it's stuck even before reaching a test :(

Logs while running:

process.env['DEBUG_FILE'] = "xxx.text"
process.env['DEBUG'] = "pw:*"

xxx.txt

Ah, I see. Sorry, I missed that the task was named "load tests". Most likely this means that one of your test files is stalling, either in top level code (just sitting in a file) or within a describe. In order to load the tests, all of this code must be executed, so if something takes too long, we can hang. However, I am unsure how this could have regressed.

I recommend filtering the tests you attempt to execute to try to narrow down the test that is causing the issue. If you use the spec path filtering, npx playwright test some-file.spec.ts, it should hopefully bypass your issue so you can actually execute.

Out of memory crashes has been a recurring problem for me for the last couple of months.
I noticed that if running npx playwright test --ui while having --ui-port=8080 --ui-host=0.0.0.0 flags set (https://playwright.dev/docs/test-ui-mode#docker--github-codespaces), to open the UI in an external browser, those crashes stopped happening.

Hopefully this helps.

@FranciscoKnebel if you have more information and can come up with a repro, we would appreciate it if you filed a new issue. This issue isn't specifically an OOM issue.

Running one test or many doesn't change anything for me

The OOM crash should now be solved with running UI Mode with DEBUG logging. However, that likely doesn't fix your root problem of tests freezing.

Ah, I see. Sorry, I missed that the task was named "load tests". Most likely this means that one of your test files is stalling, either in top level code (just sitting in a file) or within a describe. In order to load the tests, all of this code must be executed, so if something takes too long, we can hang. However, I am unsure how this could have regressed.

I recommend filtering the tests you attempt to execute to try to narrow down the test that is causing the issue. If you use the spec path filtering, npx playwright test some-file.spec.ts, it should hopefully bypass your issue so you can actually execute.

I still recommend these debugging steps.

I've tracked down issue to prisma client import import { PrismaClient, type Prisma } from "@libs/orm"; which was generated with the following config:

generator client {
  provider     = "prisma-client-js"
  output       = "../build" // `output` is required
  moduleFormat = "esm"
  runtime      = "node"
}

Steps to reproduce:

1. Install prisma
2. Generate client
3. Import prisma client in test

I am unable to reproduce. I performed the following steps:

mkdir prisma && cd prisma
npm init playwright@latest

npm i -D prisma
npm i @prisma/client

Created schema.prisma with the following contents:

datasource db {
  provider = "postgresql"
  url      = env("DB_URL")
}

generator client {
  provider     = "prisma-client-js"
  output       = "build" // `output` is required
  moduleFormat = "esm"
  runtime      = "node"
}

Generated Prisma data:

npx prisma generate

I edited tests/example.spec.ts to contain:

import { test, expect } from "@playwright/test";
import { PrismaClient } from "../build";

test("has title", async ({ page }) => {
  await page.goto("https://playwright.dev/");

  // Expect a title "to contain" a substring.
  await expect(page).toHaveTitle(/Playwright/);

  console.log(PrismaClient);
});

This executes and prints the PrismaClient object as expected.

@agg23 here is the reproduction repository, follow readme: https://github.com/ziimakc/playwright-error-reproduction