Orphaned lane browser holding the profile lock is retried blindly for 60 s; in-place extension reload after an upgrade breaks the lane

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 1mo ago ·closed by John Lauer

Summary

Two failures found while restoring pup on AdomLapper on 2026-09-19, both cost about an hour and neither is diagnosed by pup itself.

1. An orphaned lane browser holding the profile lock is retried blindly. A previous pup browser (build 152) was still alive but never called home. Every later launch printed Opening in existing browser session. to stderr and exited 0 within a second. pup's log only said the launched browser never called home within 25 s; ending it and launching once more, then relaunched into the same wall, and every pup_open_window timed out at ab's 60 s budget. Meanwhile Chrome showed a "Profile error occurred" modal on the user's screen.

2. An in-place extension reload after a pup upgrade breaks the lane. After bridge_install to 2.0.645, the running browser's worker was still 2.0.643. pup logged lane worker 2.0.643 is behind pup 2.0.645; re-staged the extension and asked the worker to reload in place, after which every pup_eval on those windows returned browser_gone while the windows and 13 browser processes were alive. The standing rule already says an in-place reload does not load new files; pup should not attempt it.

Proposals

On a cold launch, keep the child's stderr and check for Opening in existing browser session. When seen: find the pup browser tree that holds <profile>/lockfile (command line names pup-profiles), end that tree, remove the stale lock, relaunch once, and log exactly that. Never a silent 25 s wait + blind relaunch.
pup_readiness should report orphaned_browser with the pid when a pup browser exists that has not polled /extcmd in the last N seconds.
On a version mismatch between pup and the lane worker, do not reload in place. Either leave the old worker driving (it works) and cycle on the next natural browser exit, or cycle the browser explicitly (close all windows, quit, relaunch, restore windows) and say so in the log and the next verb's _hint.
A process filter in diagnostics must fail loudly if it returns nothing while the profile lock is held: a broken WMI filter reported "0 pup processes" for the whole hunt.

Found while

Restoring John's laptop after a pup restart; the actual fix was ending pid 28120 and removing adom-you/lockfile.

1 Reply

John Lauer · 1mo ago

Fixed in pup 2.0.646/2.0.647, on insiders as 2.0.647.

Orphaned lane browser: launch_extdrive now lists browser processes whose command line names the lane profile (WMI through the host) whenever the lane is not alive, ends them, and only then clears the lock. Log: ended N stale browser process(es) holding profile "adom-you" before relaunching. pup_readiness reports orphanedBrowser {pids, profile} when such a browser exists.
No in-place worker reload after an upgrade. A stale worker is cycled through the crash-restore path instead: every extension window is reserved, the lane is ended as pup's own kill, and each window is relaunched from its file on the re-staged extension, in the background, at its last page. 2.0.646 tried a bare kill and recovery forgot the windows (the pid list was cleared before recovery read it); 2.0.647 reserves and relaunches explicitly. The lane's worker version is reset on every lane kill so a leftover reading cannot trigger it.

Measured on ConfRoomROG: a window opened on the old worker survived the upgrade cycle (document.title answered after it); the launch sweep ended 9 stale processes; foreground gate, parity and smoke at baseline. On AdomLapper the wiki window opened before the 2.0.647 install answered after it.

Not done: pup does not read the child's stderr for "Opening in existing browser session" (spawn is detached); the sweep before launch makes that message impossible instead.

John Lauer closed this · 1mo ago