refactor(engine): move Chromium profile hygiene out of the wwjs adapter - #1025
Merged
Conversation
Neither of these two routines is about WhatsApp. They clean up after the operating system: a process killed with SIGKILL leaves an orphaned browser behind (Puppeteer's exit hook never runs) and stale SingletonLock/Socket/Cookie files in the profile dir that block the next launch. They change when Docker, Puppeteer or the host platform changes — never when the protocol does. They now live in chromium-profile-hygiene.ts as two free functions taking (sessionId[, sessionDataPath], logger). Neither read any adapter field beyond config and the logger, so there is no port back. The adapter keeps the --openwa-session= marker arg at launch, which is genuinely a launch-arg concern and is what makes the sweep able to identify its own orphans. whatsapp-web-js.adapter.spec.ts passes with ZERO edits — 382 tests. Both describes drive through the public initialize() and spy on shared module objects, so passing this.logger through keeps the same object under observation. The child_process import leaves with the block; execFile now appears nowhere in the adapter. 3281 to 3202 lines. Behaviour identical; both routines were already best-effort and still log at debug rather than throwing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Neither of these two routines is about WhatsApp.
killOrphanedChromiumProcessesSIGKILLs a browser orphaned when the process died hard — Puppeteer'sexit hook never ran, so the browser survives, leaking memory and pinning the profile dir.
removeStaleSingletonFilesclears theSingletonLock/Socket/Cookiethat a hard-killed Chromiumleaves behind and that block the next launch on some setups.
Both change when Docker, Puppeteer or the host platform changes. Neither changes when the WhatsApp
protocol does. That is an independent audience sitting inside the adapter that implements the protocol.
What moves
Into
chromium-profile-hygiene.ts, as two free functions taking(sessionId[, sessionDataPath], logger).Neither read an adapter field beyond
configand the logger, so there is no port back.The adapter keeps the
--openwa-session=marker arg it appends at launch: that is a launch-arg concern,and it is what lets the sweep recognise its own orphans rather than a sibling session's live browser.
The
child_processimport leaves with the block —execFilenow appears nowhere in the adapter.Success criterion
whatsapp-web-js.adapter.spec.tspasses with zero edits — 382 tests. Both describes drive throughthe public
initialize()and spy on shared module objects, and passingthis.loggerthrough keeps thesame object under observation.
Secondary:
grep -c 'execFile|SingletonLock|openwa-session='on the adapter drops to 1 — the marker arg.3281 → 3202 lines. Behaviour identical; both routines were already best-effort and still log at debug
rather than throwing.
Note on the plan this came from
The audit that prompted this listed four non-contract state machines in the adapter. Re-checked
against current source, three of them are interface-declared —
onActionRequired(
interfaces/whatsapp-engine.interface.ts:543),onCredentialTeardownStarted(:568) andclaimStuckAuthRecovery(:585). Only readiness reconciliation is genuinely non-contract, and it muststay: it reads and writes
this.statusandthis.client, and its success path arms the onboardingwatcher.
So this PR takes the audience that is cleanly separable rather than pursuing a de-classification the
interface mitigation makes inappropriate — the adapter's 81 public methods are all mandated by
IWhatsAppEngine.Verification
Backend lint,
prettier --check,tsc --noEmitover the full project including specs, build, 4012 unittests, 137 e2e tests, and the dashboard build all pass on Node 22.