pup_open_window must return early with progress on slow opens (SDK #59): heavy sites on a small VM exceed ab's verb budget while the window is created anyway

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 · 2mo ago ·closed by John Lauer

Measured on winvm (4 vCPU Azure VM, ab 2.0.97, pup 2.0.390/391) during the 2.0.390 release sweep, 2026-09-04. Opening mouser.com, ti.com/product/LM317 and an isolated-profile window took 45-65s wall clock each under load, and 60s for a Mouser product page on an idle VM. Two caps bit in sequence: pup's own server.timeout of 45s (fixed in 2.0.391, socket budget now 260s), then ab's per-verb budget - winvm's ab 2.0.97 applies 60s to pup_open_window regardless of the 150s pup declares in bridge.json, and an explicit timeoutSeconds arg does not extend it. In every case the window WAS created (it appears in pup_list_windows with its final title moments later), so the caller is told the open failed while pup succeeded; a retry with the same sessionId is then refused as owned by the same thread's earlier open, and a retry with a new sessionId duplicates the window. The Bridge SDK rule (#59) already says what to do: a long verb returns {started, jobId, statusVerb, progress} and stays pollable, never blocking past its budget. Proposed: pup_open_window budgets ~35s for window creation + navigation; if the page has not reached domcontentloaded or the post-nav stages (park re-assert, identity stamp, overlay, render probe) are still running, respond ok:true with loading:true, windowEtiquette, a progress frame {phase:'navigating', percent<100, elapsedSec, estimatedSec from history} and a _hint to poll pup_readiness active[] (which already carries in-flight opens) or pup_wait; the deferred stages continue in the background. Also record per-stage timings so the estimate is measured, not guessed. Both laptops opened the same 10 destinations in 1-7s each, so this is a small-box problem, but small boxes are exactly what new users have.

2 Replies

John Lauer · 1mo ago

Status 2026-09-14, pup 2.0.566 and later: the concrete failure here (a first open that exceeds ab 60 s while the window is created anyway) is fixed for the default extension lane. Two causes were measured and removed: the extension channel lost commands when the MV3 worker restarted mid-command, so the bridge waited out full timeouts (commands are now re-queued on a fresh hello, and the channel is a real queue since 2.0.570); and the cold-open budgets did not fit (brands 6 s, tabs 10 s, birth navigate 30 s, badge eval 25 s now). A cold open on AdomLapper returns in about 20 s. The early-return-with-progress design this issue proposes (SDK #59) is still the right shape for genuinely slow pages on small boxes and is not implemented, so leaving this open for that part.

John Lauer · 1mo ago

Implemented in pup 2.0.648 (insiders): once a cold open has spent more than 35 s and the window exists (bound, parked, owned, session saved), pup_open_window answers ok:true, loading:true with progress {phase:'navigating', elapsedSec, percent} and a hint to poll pup_window_info / pup_readiness active[], and finishes the navigate, fit and identity in a background thread (logged as 'slow open finished in the background'). The normal path is unchanged (measured: opens on ConfRoomROG return without loading, foreground gate 77 samples PASS). The slow path is exercised by code review only; no box in reach is slow enough tonight to trip the 35 s budget, so reopen with a log line if a small box still times out.

John Lauer closed this · 1mo ago