Files
orca/docs
Jinwoo-H 58e0960598 fix(browser): bound how long a wake can hold the request that triggered it
Design review found the one thing that made the "wake transparently" contract
untrue in production. A wake awaited the full 30s page-load budget, but a wake
happens inside browser.tabShow, which the paired client caps at 15s
(remote-browser-page-session.ts, remote-browser-screencast-subscription.ts). So
revealing a parked page whose site is slow reported the browser unreachable —
the same "flaky remote" symptom the original ticket is about, reintroduced by
the fix for it.

The asymmetry was mine: createTab deliberately never waits for its load, and
returns a tab that is operable and still navigating. A wake now does the same,
with a budget comfortably inside the client's, and the load continues after it
returns. Fast pages are still fully loaded when the wake resolves, which is
what an agent expects; slow ones no longer stall the caller.

Also drops the reclaimer's `close` dependency, dead since the retained-page
close was removed.

Reviewers were unanimous that park-and-wake is the right mechanism, the main
process the right owner, and command activity the right signal; both other
lenses returned no merge blocker.
2026-08-19 19:07:13 -04:00
..