Skip to content

fix(run): reuse discovery browser instead of leaking it (#167) - #173

Open
JonasJesus42 wants to merge 1 commit into
mainfrom
fix/run-discovery-browser-leak
Open

fix(run): reuse discovery browser instead of leaking it (#167)#173
JonasJesus42 wants to merge 1 commit into
mainfrom
fix/run-discovery-browser-leak

Conversation

@JonasJesus42

@JonasJesus42 JonasJesus42 commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Problem

parity run was leaking a whole Chromium process on every run with auto-selectors enabled.

runSelectorDiscoveryPass() was changed in #167 to keep its live-validation Chromium open and hand it back to the caller for reuse (to avoid a second launch that OOMs low-RAM machines). e2e.ts consumes this correctly. But run.ts discarded the return value (await runSelectorDiscoveryPass({...})) and then launched a separate browser. Result: the discovery/validation Chromium stayed alive, orphaned, for the entire run — a resident process alongside the main browser.

When several parity runs execute in parallel (e.g. inside Conductor), the extra resident Chromium per run drives total RSS up until the OS OOM killer starts SIGKILL-ing processes (exit 137) — often a sibling process rather than parity itself.

Fix

Mirror the e2e.ts pattern in run.ts:

  • Capture the returned browser into discoveryBrowser.
  • Reuse it as the main browser (discoveryBrowser ?? await launchBrowser(...)).
  • The existing SIGINT/timeout shutdown handler and outer finally already close browser, so cleanup is covered.

Net effect: 1 fewer resident Chromium per parity run (and one fewer launch → faster).

Verification

  • bun run check (tsc) passes.
  • Manual: ps aux | grep -iE "Chromium|headless_shell" during a run — was 2+ resident, now 1; 0 after completion.

Part of a series addressing memory pressure / OOM during parity runs. Follow-ups: safeBodySize body-buffering, single-browser preflight, HTML trimming.

🤖 Generated with Claude Code


Summary by cubic

Reuses the live-validation browser from auto-selector discovery in parity run instead of launching a second Chromium. This removes the leaked process per run, cuts memory use, and slightly speeds up runs.

  • Bug Fixes
    • Capture discoveryBrowser from runSelectorDiscoveryPass() and use it as the main browser (fallback to launchBrowser when absent).
    • Rely on existing SIGINT/timeout and finally cleanup to close the reused browser.
    • Net result: single Chromium per run and fewer OOM/exit 137 incidents.

Written for commit 67d8cc9. Summary will update on new commits.

Review in cubic

`parity run` called runSelectorDiscoveryPass() and discarded its return
value. Since #167 that function keeps the live-validation Chromium OPEN
and hands it to the caller for reuse (e2e.ts already consumes it). run.ts
ignored it and launched a second browser, leaving the discovery Chromium
orphaned for the entire run — a resident process that, alongside the main
browser and sibling agents, pushed machines into the OOM killer (exit 137).

Capture the returned browser as `discoveryBrowser` and reuse it as the main
`browser` (falling back to a fresh launch when null), mirroring e2e.ts. The
existing SIGINT/timeout `shutdown` handler and outer `finally` now close it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.

1 participant