[Bug]: VSCode extension aborts run after a single slow (>10s) API test — subsequent tests never execute despite

[bencelados]

Version

1.60.0

Steps to reproduce

Environment:

Playwright @playwright/test ^1.60.0
Playwright Test for VSCode extension (latest)
VS Code on Windows 11
Test type: REST API (no browser, uses Playwright request fixture)
Config: workers: 1, fullyParallel: false, per-test timeout: 30_000

Reproduction:

1. Test suite with 80 API tests using request fixture (no browser)
2. Backend has tests in the 10-17s range due to slow live API
3. Click "Run All" from Test Explorer
4. Observe: extension runs first ~57 fast tests successfully
5. When the first slow test starts (installations.equipment.by-id, ~17s wait on backend), the extension's UI top counter changes from 57/80 to 57/57
6. The slow test completes in the underlying Playwright process (terminal output shows ok 58 ... (17.0s)) but the result is dropped from the UI
7. All subsequent tests (59-80) are never executed — they remain in ○ state forever

Even smaller reproductions: a 3-test folder containing one 17s test as test #1 — only ok 1 completes; tests 2-3 never run.

Expected behavior

All 80 tests execute sequentially under workers: 1; UI shows results for each.

Actual behavior

Extension aborts the session ~15-17s after a slow test starts, regardless of remaining tests.

Additional context

Workaround: Use npx playwright test from CLI — runs all 80 successfully in ~96s.

Hypothesis: Extension's IPC heartbeat to the test-server has a shorter timeout than per-test timeout. API tests block on request.fetch() without progress events, exceeding the heartbeat threshold even though the test itself is healthy.

Environment

System:
    OS: Windows 11 10.0.26100
    CPU: (14) x64 Intel(R) Core(TM) Ultra 7 155U
    Memory: 3.41 GB / 31.51 GB
  Binaries:
    Node: 24.13.1 - C:\Program Files\nodejs\node.EXE
    npm: 11.12.1 - C:\Program Files\nodejs\npm.CMD
  IDEs:
    VSCode: 1.120.0 - C:\Users\gsgbla\AppData\Local\Programs\Microsoft VS Code\bin\code.CMD
    Claude Code: 2.1.45 - C:\Users\gsgbla\AppData\Roaming\npm\claude.CMD
  npmPackages:
    @playwright/test: ^1.60.0 => 1.60.0

[dgozman]

@bencelados Could you please provide a repro that we can run locally? It's hard to make any fixes without a reproduciton.

[bencelados]

@dgozman — thanks for the quick response. Update with diagnostic details.

TL;DR

The bug does reproduce on the original project (a private REST-only Playwright test suite), confirmed on two different machines (mine + a colleague's, same Windows + same extension version). I tried 5 progressively richer minimal reproductions in a side project and none of them triggered the bug — but I captured a clear error from the VS Code Developer Tools console during a failing run on the real project:

ERR [Extension Host] Error: runTests: test server connection closed
at Me._sendMessage (c:\Users\gsgbla.vscode\extensions\ms-playwright.playwright-1.1.19\out\extension.js:107:13120)
at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
at async Me.runTests (extension.js:107:14806)
at async ft.runTests (extension.js:109:974)
at async us.runTests (extension.js:110:9212)
at async Et._runTest (extension.js:147:14353)
at async Et._runTests (extension.js:147:12050)

The Test Explorer UI shows no error — the run just "completes" at 57/57 (instead of 80/80), with the remaining tests stuck in queued state.

Symptom on the real project

• 80 sequential API tests (no browser; request fixture / APIRequestContext), workers: 1, fullyParallel: false
• A typical test does list({ pageSize: 100 }) → getById(...) against a slow internal API
• A custom log fixture writes one testInfo.annotations.push() (INFO) + one testInfo.attach() (DEBUG JSON, ~100–500 KB) per HTTP call
• Test feat(browser): add Browser.userAgent() and browser.version() for WebKit #58 is installations.equipment.by-id — its two HTTP calls together block for ~17 s
• CLI: npx playwright test → all 80 pass green in ~96 s
• Test Explorer: after test feat(browser): add Browser.userAgent() and browser.version() for WebKit #58 finishes, the extension throws the error above and the remaining 22 tests are silently dropped from the UI

What I tried to reproduce (none of these triggered it)

A side project playwright-vscode-repro-40889 (still local, can push to GitHub if useful) tried 5 progressively richer variants:

Variant	What it does	Result
v1	5 tests, default request fixture, 1 slow test (17 s) at position 3	Passed — no repro
v2	63 tests, same shape, slow at position 58	Passed — no repro
v3	63 tests + testInfo.attach() per test (~140 KB JSON each, ~9 MB total)	Passed — no repro
v4	63 tests + full 5-fixture chain mimicking the real project (apiContext test-scoped with dispose(), log fixture writing INFO + DEBUG attach per call, resources client doing list-then-pick)	Passed — no repro
v5	64 tests + ~1 MB JSON payload per call + simulated synchronous schema-validate CPU work + two consecutive slow tests at the boundary	Passed — no repro

So at least none of these are sufficient to trigger the bug:

• Test count alone (up to 64)
• Attachment volume up to ~125 MB / run
• A 17 s blocking HTTP call with no progress events
• APIRequestContext lifecycle re-instantiation per test
• ~50 ms of synchronous CPU work between HTTP calls
• Two back-to-back slow tests

Hypothesis (open to correction)

A heartbeat or idle-timeout on the IPC between the extension and the test-server is shorter than the 17 s blocking HTTP call. During the slow test's silence the test-server connection is closed by one side; the extension catches the close only when it next tries _sendMessage to dispatch the following test. The currently-running slow test still completes in the test-server process and writes its result to the terminal (visible in the list reporter output as ok 58 ... (17.0s)), but the extension never receives that result and never dispatches tests 59+.

I have a strong suspicion that something specific to the project (real HTTPS to a slow backend, or some interaction between the fixture stack and testInfo.attach's implementation, or the ~80-test surface) is the trigger, but I can't pin it down on a minimal repro.

Environment

• OS: Windows 11 (10.0.26100)
• Node: 24.13.1, npm: 11.12.1
• @playwright/test: 1.60.0
• Playwright Test for VSCode extension: 1.1.19
• VS Code: <fill in from Help → About>
• Test type: REST API (no browser, uses request / APIRequestContext)
• Config: workers: 1, fullyParallel: false, per-test timeout: 30_000

How I can help further

1. Happy to push the side-project repro (v1–v5) to a public GitHub repo if you want to triage why those don't trigger it (it's possible they're missing a single dimension I haven't thought of).
2. I can also prepare a sanitized fork of the actual project with the HMAPI replaced by a local mock, but that would take a few hours and is only worth it if you'd be willing to dig into it — let me know.
3. If there's a specific Playwright trace flag (PWDEBUG=, DEBUG=pw:server:*, etc.) or extension setting that would surface the IPC close reason on the test-server side, happy to capture that.

[dgozman]

@bencelados Thank you for diagnostics. Unfortunately, that does not really help. The proposed hypothesis is incorrect (there is no idle timeout or hearbeat, and the test server connection is never closed on purpose), and we still don't have a repro, so we won't be able to help.

[bencelados]

@dgozman - found the actual root cause, fully my fault, sharing in case it's useful UX feedback for the extension.

Root cause: the project's custom log fixture writes a testInfo.attach() JSON payload containing the full request + response body per HTTP call when LOG_LEVEL=debug. One of the HMAPI list-GET endpoints returns 100 entities, some with embedded base64 image attachments. Total response size: ~180 MB per call (188,529,778 characters). Across 57 tests with various large responses, this accumulates to 2+ GB of in-memory state in the Test Explorer (Task Manager showed node.exe > 2 GB and disk I/O > 70 MB/s before the connection closed).

CLI is unaffected because it streams attachments to disk without retaining them in memory the way the Test Explorer needs to for UI display.

Closing this on my side - LOG_LEVEL=info (the default in CI) works fine, and we'll truncate DEBUG attachments to fix the dev workflow case. Thank you for engaging.