[Bug] Session health check rebuilds Chrome with a fresh profile when the driver's backend-tab connection is lost — discards login state

[galaxyeye]

[Bug] Session health check rebuilds Chrome with a fresh profile when the driver's backend-tab connection is lost — discards login state

Repo: platonai/Browser4 · Module: browser4-rest (ai.platon.pulsar.rest.session.PulsarSessionManager)
Component: Session health check / auto-replacement
Severity: Medium — silent loss of interactive session state (manual logins, cookies, form state)
Version observed: browser4 runtime v4.13.5 (CLI backend), Windows 11, headed Chrome

---

Summary

When the driver link to a session's backend tab is lost while the browser process itself is still healthy, the session health check declares the session "unhealthy" and rebuilds the whole browser with a fresh profile (a new cx.NNN user-data dir). Any state that lived in the old profile — most importantly a manual GitHub (or any site) login — is silently discarded, and the user sees an anonymous, logged-out browser.

In our reproduction, the driver link died after the machine went through Modern Standby (Windows S0 sleep). After wake, eval/snapshot still worked for ~20 minutes, then the first click hung (CDP DOM.getContentQuads got no response for 30 s), and the health check immediately tore down the session.

Steps to reproduce

1. browser4-cli -s demo open --headed "https://github.com/<repo>" (any site with a login).
2. Log in manually in the visible window (e.g., GitHub).
3. Let the machine enter Modern Standby (sleep) for a while, then wake it. (Alternative trigger: manually close the hidden "backend tab" the driver bridges through, if visible in the tab strip.)
4. Interact with the page through the CLI — e.g. browser4-cli -s demo click <ref>.
5. Observe: the click hangs ~30 s and fails; the backend then replaces the session with a brand-new Chrome profile, and the manual login is gone.

Observed behavior (log evidence, local times)

19:39:03  (Windows event log: Kernel-Power 507/566 — exiting Modern Standby)
...
19:52:29  Calling tool: browser_click --ref=backend:8631 --sessionId=...
19:52:34  RobustRPC: Oop, a bit slip-up executing action: [evaluateDetail], retrying 1/2 time ... | Timed out waiting for 5000 ms
19:53:04  ClickableDOM: Failed to get content quads for node 3682
          ChromeRPCTimeoutException: No response | DOM.getContentQuads | #5, (PT30S)
19:53:04  PulsarSessionManager - Bound driver 4 is unhealthy, state: INIT
19:53:04  Session <id> is unhealthy: session active=true,
          browser healthy=CheckState(code=0, message=Browser is healthy, scope=),
          driver  healthy=CheckState(code=503, message=WebDriver is not open - the connection to the backend tab is lost, scope=)
19:53:04  Cached session <id> is unhealthy, creating a replacement
19:53:05  ChromeLauncher - DevTools listening on ws://127.0.0.1:19096 (NEW Chrome, fresh profile cx.002)

Key observations:

• The browser itself was healthy (code=0) — the visible window kept working fine the whole time; only the driver→backend-tab link was dead (code=503, driver stuck in INIT).
• The replacement used a new user-data dir (cx.001 → cx.002), so profile-scoped state (cookies, logins) was lost.
• A plain CDP attach to the old Chrome (ws://127.0.0.1:56233/...) still worked afterwards — the old browser and its profile were perfectly usable; only the backend's bookkeeping about them was broken.
• The health check fired on the next CLI interaction after the link died, so the failure is user-visible as a random "session reset".

Expected behavior

A dead driver link should not destroy the session's browser/profile. Prefer, in order:

1. Reconnect / recreate the backend tab for the existing browser (the driver is in INIT — let it finish re-initializing against the same Chrome), or
2. Keep the old profile when rebuilding (reuse the same user-data dir), or
3. At least fail the operation loudly instead of silently swapping to a fresh anonymous browser.

The health check should distinguish "browser process dead" (rebuild warranted) from "browser healthy but driver link lost" (recover the link). Note the log line even prints browser healthy=code=0 immediately before deciding to throw the browser away.

Suggested fix direction

In PulsarSessionManager (see is unhealthy/creating a replacement around lines 159–220 and 719–721 of browser4-rest/src/main/kotlin/ai/platon/pulsar/rest/session/PulsarSessionManager.kt):

• When browser healthy == OK but driver healthy == 503 (backend-tab link lost), attempt a driver re-init against the existing Chrome (the driver is already in INIT state) with a bounded retry, instead of creating a replacement.
• Only fall back to profile-preserving rebuild if re-init fails.
• Consider a config/flag to disable auto-replacement for interactive (headed) sessions, since silent profile swaps are especially harmful there.

Workarounds

• After logging in manually, save the session state (browser4-cli state-save) so it can be restored after a rebuild.
• Operate via direct CDP attach to the headed Chrome (browser4-cli attach --cdp http://127.0.0.1:<port>, or raw page-level CDP) to bypass the session manager entirely.
• Avoid machine sleep while a headed interactive session is mid-work.

Repro notes

• Triggering link death: machine Modern Standby (Windows 11, S0) is a reliable repro; manually closing the backend tab should also work.
• Affects all headed interactive workflows that require manual login (GitHub, cloud consoles, etc.).

[galaxyeye]

Fix implemented on \4.13.x\ (commit \3ebcf49b), tagged \�4.13.7-ci.1\ for CI:

• \PulsarSessionManager.recoverLostDriverLink(): when the browser is healthy but the driver link is lost, bind a fresh driver on the same browser instance (same Chrome profile — cookies/logins preserved) instead of rebuilding with a fresh profile.
• Falls back to the previous recreate path when the browser itself is dead or recovery fails.
• Regression test: \sessionWithLostDriverLinkIsRecoveredWithoutRecreatingBrowser\ (18/18 tests green locally).

[galaxyeye]

Second round of fixes on 4.13.x (commit 1b4fde00), tagged v4.13.7-ci.2:

Review found the attach flow had the same fresh-profile disease:

1. AbstractPulsarSession.createBoundDriver ignored an already-bound browser (e.g. after attach --cdp) and launched a brand-new Chrome on first use — the attached browser's profile (login) was silently discarded.
2. createAttachedSession never set SessionKind.CDP_ATTACHED, so the existing "non-owned sessions are never recreated" guard was dead code — all sessions defaulted to BROWSER4_LAUNCHED.

Fixes: reuse the bound browser when creating the driver; mark attach sessions CDP_ATTACHED (and swarm sessions SWARM). Tests: CreateBoundDriverTest + attached-session-kind test (20/20 green locally).

[galaxyeye]

Base-library fix on platonai/Browser4base 4.11.x (commit 5c2c7e37, tag v4.11.4-ci.1):

Added an explicit CDP link reconnect capability so a lost websocket (machine sleep) no longer leaves the driver permanently stuck:

• Transport.reconnect() / KtorTransport — resets the closed flag, recreates the receiver-loop scope, re-establishes the websocket to the same URI (message consumers retained)
• ChromeDevToolsService/ChromeDevToolsImpl.reconnect() — re-establishes browser + page transports
• BrowserProtocol/DirectChromeProtocol.reconnect() — delegates to devtools
• WebDriver/PulsarWebDriver.reconnect() — re-establishes the protocol, re-enables CDP agents (Page/DOM/Runtime/Network/CSS), reports health

Tests: real-websocket transport reconnect + devtools + driver delegation (8/8; full pulsar-browser suite 478 green).

Integration note: PulsarSessionManager.recoverLostDriverLink in this repo currently recovers by creating a new driver on the same browser. Once a browser4base release containing this fix is published and this repo bumps browser4-base.version, the recovery can try staleDriver.reconnect() first — preserving the exact same tab.