@clerk/testing: signIn() times out with concurrent Playwright workers (--workers=2+)

[joerizz23]

Description

When using @clerk/testing with Playwright and --workers=2 (or more), all tests fail with TimeoutError: page.waitForFunction: Timeout 15000ms exceeded at clerk.signIn(). With --workers=1, authentication works 100% reliably.

Environment

• @clerk/testing: 1.13.36
• @clerk/nextjs: latest
• @playwright/test: 1.57.0
• Next.js: 15.4.11
• OS: Windows 11 (also likely affects Linux/macOS)
• Auth strategy: emailAddress

Reproduction

1. Set up a Next.js app with Clerk authentication
2. Create a Playwright fixture using @clerk/testing:

import { clerkSetup, clerk } from "@clerk/testing/playwright";

// In fixture:
await clerk.signIn({
  page,
  emailAddress: testUser.email,
});

3. Run tests with --workers=1 → all tests pass
4. Run tests with --workers=2 → all tests fail

Error

TimeoutError: page.waitForFunction: Timeout 15000ms exceeded.

  at loaded (node_modules/@clerk/testing/src/playwright/helpers.ts:100:14)
  at Object.b (node_modules/@clerk/testing/src/playwright/helpers.ts:120:9)

The timeout occurs at the window.Clerk?.loaded === true && window.Clerk?.user !== null wait inside signIn().

Analysis

Each Playwright worker creates a separate browser instance. When 2+ workers call clerk.signIn() concurrently:

• setupClerkTestingToken() injects the dev-browser token into each browser
• Both browsers navigate and wait for window.Clerk.loaded && window.Clerk.user
• The wait times out on both workers

Possible causes:

1. Clerk Backend API rate-limits concurrent testing token validations from the same publishable key
2. ClerkJS client-side hydration conflicts between concurrent browser sessions
3. The dev-browser token mechanism doesn't support multiple simultaneous sessions

Expected Behavior

@clerk/testing should support concurrent Playwright workers, or the documentation should explicitly state that --workers=1 is required.

Suggested Improvements

• Support parallel test users with isolated Clerk sessions
• Provide a testing mode that doesn't require live ClerkJS hydration (e.g., a static token that bypasses the window.Clerk.loaded wait)
• Document the --workers=1 limitation if concurrent sessions aren't supported

[m13v]

We hit almost the exact same issue when running concurrent Playwright sessions against our own auth system. The root cause in our case turned out to be that all workers were fighting over shared browser state, not an API rate limit.

The fix that worked for us was assigning each Playwright worker its own isolated browser profile directory (user-data-dir) and wrapping browser launches with a file-based lock so no two workers ever touch the same profile simultaneously. Even if the sessions are logically independent, Chrome can behave unpredictably when multiple processes try to initialize from overlapping temp directories.

In your case, I suspect the ClerkJS hydration is timing out because the dev-browser token injection is colliding across workers. Each worker's browser instance might be overwriting or invalidating the token that another worker just set. If you can force each worker to use a completely isolated browser context (not just a new page, but a new browser instance with its own storage), the concurrent hydration should work.

One practical workaround while waiting for a proper fix: pre-authenticate each worker with a dedicated test user and save the storage state to separate JSON files, then load each worker's state from its own file rather than calling signIn() concurrently.

[m13v]

Here is the lock script we use for isolating concurrent Playwright sessions so they do not collide on shared browser state: https://github.com/m13v/browser-lock/blob/main/playwright-lock.sh

It wraps each browser launch with a file-based exclusive lock per profile directory, which prevents exactly the kind of token injection collision you are seeing with multiple workers.