microlinkhq / browserless / 36873376032

81%

push

github

feat(function): take the page from the target instead of enumerating (#954)

`browser.pages()` is not a listing. It builds a `Page` for every page
target on the browser, one CDP session each, including pages other
contexts own and may be navigating:

  Browser.pages()        -> every browserContext
  BrowserContext.pages() -> targets().filter(type page).map(t => t.page())
  Target.page()          -> _sessionFactory() then CdpPage._create

Production, 30 samples of `({ page }) => page.title()` on 3.72.0, where
the spans landed:

  require=45 connect=109 pages=7483 resolve=0 run=32  total=9385
  require=34 connect=31  pages=1327 resolve=0 run=4   total=2869
  require=29 connect=38  pages=335  resolve=0 run=8   total=3069
  require=32 connect=32  pages=19   resolve=0 run=5   total=1550   24 of 30

Every slow request is `pages`, 15ms to 7483ms. `connect` holds 26-109ms
throughout, including the 9.4s one, so it was never the cause.

This is #952 fixed one layer too late. That removed the session round trip
from the scan, which is why `resolve` reads 0 on all 30, but the
enumeration that builds the array it scanned still pays a session per
page. The scan was the right neighbourhood and the wrong call.

The target registry is local state, so a caller that already supplied
`targetId` pays for its own page alone. Measured against a browser with
four contexts open:

  pages()=8.6ms (n=5)   targets().find().page()=1.4ms

End to end the span disappears rather than shrinking, and with three
decoy pages marked it still resolves the right one:

  require=7 connect=10 target=5 run=1 disconnect=0   value "PAGE-2"

`_targetId` is private, as in #952, so a miss falls through to the
existing enumerate-and-scan rather than failing with PAGE_NOT_FOUND, and
a request with no `targetId` keeps the old path untouched.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

1379 of 1623 branches covered (84.97%)

Branch coverage included in aggregate %.

32 of 32 new or added lines in 1 file covered. (100.0%)

5960 of 7468 relevant lines covered (79.81%)

67446.45 hits per line