Skip to content

fix(browser): close the pages of a project that has no tests left - #10991

Open
JCQuintas wants to merge 1 commit into
vitest-dev:mainfrom
JCQuintas:fix/close-idle-browser-pages
Open

fix(browser): close the pages of a project that has no tests left#10991
JCQuintas wants to merge 1 commit into
vitest-dev:mainfrom
JCQuintas:fix/close-idle-browser-pages

Conversation

@JCQuintas

@JCQuintas JCQuintas commented Aug 18, 2026

Copy link
Copy Markdown

Written by an AI agent (Claude) on behalf of @JCQuintas, who has reviewed it.

Closes #10990.

In browser mode a project's pages stay open until the whole run ends, because only the provider's close() closes them. Each project opens up to maxWorkers pages and they all run concurrently, so the peak is projects * maxWorkers. Projects that finish early hold their pages, and everything their tests loaded into them, until the slowest one is done.

This adds an optional closePage(sessionId) to BrowserProvider, implemented for Playwright, and closes a session's pages once its project has no test files left. BrowserSessions tracks the results still being handled, so a page is not closed while they arrive. Watch mode keeps the pages, so reruns reuse the session.

The close is not awaited inside the run, since a browser that stopped answering would hold up the other projects. The pool's close() awaits it instead, bounded by the existing PROVIDER_CLOSE_TIMEOUT.

In the reproduction from #10990 the open-page count drops from 6 to 0 as the projects finish, instead of staying at 6. For scale, mui-x has 21 browser projects with maxWorkers: 2: 42 tabs, peaking around 12.8GB against a 16GB CI container, where a renderer gets OOM-killed and the run fails with Browser page crashed while every test passes.

@netlify

netlify Bot commented Aug 18, 2026

Copy link
Copy Markdown

Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit e2b87a7
🔍 Latest deploy log https://app.netlify.com/projects/vitest-dev/deploys/6a86e96e0344360008df210a
😎 Deploy Preview https://deploy-preview-10991--vitest-dev.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
🤖 Make changes Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

@sheremet-va sheremet-va left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have very strong race condition vibes here, but can't pinpoint it. closePage is never properly awaited which seems dangerous

Comment thread packages/browser-playwright/src/playwright.ts Outdated
Comment thread packages/vitest/src/node/pools/browser.ts Outdated
@JCQuintas
JCQuintas marked this pull request as draft August 18, 2026 10:56
@JCQuintas
JCQuintas force-pushed the fix/close-idle-browser-pages branch 6 times, most recently from 4f53657 to 493b16f Compare August 20, 2026 14:50
Browser pages were only closed by the provider's `close()`, which runs once the
whole workspace run is over. Projects run concurrently and each opens up to
`maxWorkers` pages, so a run held `projects * maxWorkers` pages at its peak and
the projects that finished early kept their page alive until the slowest one
was done.

Add an optional `closePage` to `BrowserProvider`, implement it for Playwright,
and call it from the pool once a session has no test files left. The results of
the last test can still be on their way when that happens, so the session waits
for them to be handled before its page goes away.

In watch mode the pages are kept so that reruns still reuse the session.
@JCQuintas
JCQuintas force-pushed the fix/close-idle-browser-pages branch from 493b16f to 2552767 Compare August 20, 2026 15:01
@JCQuintas
JCQuintas marked this pull request as ready for review August 20, 2026 15:19
@JCQuintas

Copy link
Copy Markdown
Author

I have very strong race condition vibes here, but can't pinpoint it. closePage is never properly awaited which seems dangerous

Yeah, it is hard to understand what is actually an error with the flaky CI failing every other push 😆

The code should now be more sound with the startUpdate/finishUpdate hooks and the wait pools. There might be better approaches to this, though I didn't want to change the code too much. Suggestions are welcome ofc.

@JCQuintas
JCQuintas requested a review from sheremet-va August 20, 2026 15:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Browser mode keeps the pages of finished projects open until the end of the run

2 participants