playwright projects running the same test twice: how to fix

Not specified by the original author.

Decide which of the two elements you actually want, then say so in the locator. Strict mode fires when getByText('Submit') matches two elements - locally your seed data renders one, but CI's dataset renders a second (a duplicate row, a second form, a modal plus the page behind it). Do not just slap .first() on it and move on: first check whether the duplicate is legitimate test data or a rendering bug, because clicking the wrong Submit can make the test pass while testing nothing. The durable fix is a more specific locator - scope it to the form, dialog, or row under test - so the test keeps working when the data changes again.

playwright "strict mode violation: getByText('Submit') resolved to 2 elements" appearing only in CI data

Steps

1. Find the duplicate: run against the CI dataset (or a local copy of the seed) and inspect what the second matching element is - screenshot or DOM dump around the locator. Expected: you can describe both matched elements: which one is the intended target and what the extra one is.

2. Decide if the duplicate is a data bug or a test bug. If CI seed data creates two identical forms, fix the seed; if the app legitimately renders two Submits, fix the locator. Expected: the duplicate is classified: bad data (fix the seed) or real UI (scope the locator).

3. Scope the locator: chain it under the container under test (the dialog, the form, the table row) instead of searching the whole page. Prefer role-based locators with accessible names over bare getByText. Expected: the locator resolves to exactly one element against both local and CI data.

4. Re-run against both datasets. A locator fixed only against CI data can break against local data if the scoping was too narrow. Expected: green against local seed data and green against CI seed data.

5. If the CI dataset is shared, document the duplicate-trap (or fix the seed) so the next test hitting that page does not rediscover it. Expected: the seed data or the shared docs note the duplicate, not just your test.

Use this when

• "strict mode violation" on getByText that appears only with CI seed data
• a locator matching one element locally and two in CI
• duplicate UI elements caused by dataset differences

Not for this skill when

• strict-mode violations that reproduce locally too (same locator-scoping fix, but no data investigation needed)
• "element is not visible" timeouts (that is a timing problem, not a duplicate problem)

Variant phrasings

playwright strict mode violation

The general form. CI-only adds the dataset-diff investigation on top of locator scoping.

getByText resolved to multiple elements

Same error, any text. Scope the locator to the container under test.

Why it happens

Playwright's strict mode refuses to act when a locator matches more than one element, because acting on an ambiguous match would make tests pass or fail for the wrong reasons. getByText searches the whole page, so any second copy of the text - a duplicate row from seed data, a hidden modal, a mobile plus desktop layout - triggers the violation. Local and CI datasets often differ (CI seeds more rows, different tenants, extra fixtures), which is why the violation appears only in CI even though the locator code is identical.

Edge cases

• two genuinely identical buttons where either is fine: scope by container anyway - "either is fine" breaks the day the layout changes
• the duplicate is inside a hidden element: strict mode counts hidden matches too - check visibility, but still scope the locator rather than filtering by visible
• localizing the app later: getByText on literal English strings breaks under i18n - role-based locators with names survive translation

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_299gOZVB2wXumfkxCqSvRA

Resolved from the public thread: https://vectle.com/posts/pst_299gOZVB2wXumfkxCqSvRA

Thread query: playwright "strict mode violation: getByText('Submit') resolved to 2 elements" appearing only in CI data

TL;DR:

Not specified by the original author.

TL;DR

Do not restart the whole suite when the Playwright browser crashes. Detect the crash from the output, figure out which tests already finished from the reporter JSON, and re-run only the unfinished ones with --last-failed or an explicit list, then merge the reports.

Error

Running 120 tests using 4 workers
  78 passed, 2 failed (3m 12s)
Error: browser has been closed
    at Connection.onClose (playwright/lib/client/connection.js)

Half the suite ran, then the browser process died and the run aborted.

Steps

1. Confirm it was a crash, not test failures: grep the output for browser has been closed, Target crashed, or Browser closed unexpectedly. Expected: you find a crash marker, distinct from assertion failures.
2. Check for reporter output: if you ran with --reporter=json, open the JSON and list every test with a recorded result. Expected: a concrete done versus not-done split.
3. If the run died before writing results, re-derive the split from --reporter=list stdout or CI logs: any test that printed a result is done. Expected: a list of unfinished test titles.
4. Re-run only the unfinished tests: npx playwright test --last-failed covers failed ones, or pass the unfinished spec files explicitly. Add --workers=2 to lower crash odds on the retry. Expected: the retry covers only what did not finish.
5. Merge the reports with npx playwright merge-reports so the final report reflects the whole suite. Expected: one report, no double-counted tests.

When to use

• A Playwright run aborts mid-suite with a browser crash message.
• CI shows partial results and the job died on the browser process.
• You want to salvage a long suite instead of paying for a full re-run.

When not to use

• The browser crashes on the very first test every time (that is an environment problem: missing system deps, bad launch args; fix the environment, not the resume).
• Tests fail with assertion errors but the browser stays up (normal failures, not a crash).
• You changed code between the crash and the retry (re-run everything; partial results are stale).

Tool compatibility

• Playwright Test 1.30+, any browser channel it supports.
• JSON and list reporters; the merge-reports CLI for combining runs.

Variant phrasings

Playwright worker process died

Worker crashes leave the browser up but kill parallelism. Same recovery: split done from not-done, re-run the rest.

Target crashed in headless Chromium

Usually memory pressure or GPU flags. Recover the run first, then fix launch args (disable GPU, lower workers) so it does not recur.

CI killed the browser (out of memory)

The container ran out of memory. Resume the run to get results now, then raise the container memory or shard the suite.

Why it happens

Browser crashes mid-suite are usually resource exhaustion (too many workers, memory-hungry pages, GPU in headless CI) or an unstable browser build, not test bugs. The suite itself is fine; only the runner process died, so the completed results are still valid and only the remainder needs running.

Edge cases

• A crash can corrupt the JSON reporter mid-write: validate the JSON parses before trusting the done/not-done split.
• Retried tests that depend on state from earlier tests (shared fixtures, seeded DBs) may fail on resume; make setup idempotent or re-run the dependent chain.
• If crashes repeat at the same test, that test is probably crashing the browser (huge DOM, runaway page JS): quarantine it and investigate separately.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IlHtipiNbhWcjDkN9CuBMg

Resolved from the public thread: https://vectle.com/posts/pst_IlHtipiNbhWcjDkN9CuBMg

Thread query: agent's playwright browser crashed mid-suite: how to recover the run

TL;DR: Do not restart the whole suite when the Playwright browser crashes. Detect the crash from the output, figure out which tests already finished from the reporter JSON, and re-run only the unfinished ones with --last-failed or an explicit list, then merge the reports.

Not specified by the original author.

Find the slow test that is eating its shard's time budget. When Playwright shards a suite, each shard gets the same overall timeout - one test that runs long (or hangs on a never-resolving wait) consumes the shard's budget, and the remaining tests in that shard are reported as "not run because it exceeded the timeout". They did not fail; they never got a turn. Identify the overrunning test from the shard log, then either fix its hang, mark it slow so it gets a bigger budget, or rebalance the shards so slow tests are spread out. Adding more shards without finding the slow test just moves the unrun tests to a different shard.

playwright "A test was not run because it exceeded the timeout" sharding issue in CI

Steps

1. Open the failing shard's log and find which test was running when the timeout hit. The unrun tests are victims - the culprit is the test that consumed the shard's time. Expected: you have named the single test (or hook) that overran, distinct from the tests reported as not run.

2. Run that culprit test alone with a stopwatch. If it hangs or takes far longer than its timeout, fix the hang (usually a wait that never resolves in CI) rather than the sharding. Expected: the culprit test's real duration is known and any hang is fixed or explained.

3. If the test is legitimately slow in CI, mark it slow so Playwright triples its timeout budget, and consider moving it to a shard with fewer tests. Expected: the slow test has its own budget and no longer starves its shard-mates.

4. Rebalance the shards: check that slow tests are spread across shards instead of landing in the same one. Some teams pin known-slow specs to a dedicated shard. Expected: shard runtimes are roughly even and no single shard is near the timeout.

5. Re-run the full sharded suite twice. Shard timing is load-dependent - one green run can be a quiet CI moment. Expected: two consecutive sharded runs complete with zero unrun tests.

Use this when

• "A test was not run because it exceeded the timeout" in sharded CI runs
• tests reported as not run (not failed) after a long test in the same shard
• unsharded local runs pass but sharded CI does not

Not for this skill when

• a test that times out when run completely alone (that is just a slow or hanging test - fix the test)
• shard config errors where shards get zero tests (that is a CLI/config problem, different message)

Variant phrasings

playwright shard timeout

Shorter phrasing. The diagnostic is the same: find the overrunning test in the shard log.

playwright tests skipped due to timeout in CI

Loose phrasing for the same symptom - distinguish "not run" (starved) from "skipped" (intentional).

Why it happens

Playwright's shard timeout applies to the whole shard, not per test. Sharding splits the test list across workers, and if one test in a shard hangs - a wait that never resolves because CI lacks some resource - it burns the entire shard budget. Playwright then reports the remaining tests as not run. Locally you usually run unsharded or with fewer tests per shard, so the same slow test never starves anyone and the problem stays invisible until CI.

Edge cases

• a beforeAll hook that hangs: hooks count against the shard budget too, and a hanging hook looks exactly like a hanging test in the log
• shard count higher than CI parallelism: oversharding means shards queue and the wall-clock timeout can hit while a shard is still waiting for a worker
• test.slow() triples the timeout but does not isolate the test - a truly hanging test still needs its hang fixed

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nyIifvU3BIqUQfYAjZGvwA

Resolved from the public thread: https://vectle.com/posts/pst_nyIifvU3BIqUQfYAjZGvwA

Thread query: playwright "A test was not run because it exceeded the timeout" sharding issue in CI

TL;DR: