Wait for a page target before resizing the display

[yummybomb]

Summary

PATCH /display and the display step of /chromium/configure can return 500 no page target found right after Chromium starts or restarts. DevTools can accept connections shortly before Chromium opens its first tab, and firstPageTargetID looked up the page target once and failed on an empty result. In the server e2e suite this shows up as intermittent failures in whichever test resizes first, such as TestReplayRecordingIncludesAudioTrack, TestDisplayResolutionChange, or TestChromiumConfigureMultipartPowerset/display. Re-running the job usually passes.

firstPageTargetID now polls Target.getTargets every 100ms for up to 5s, with the last sleep clamped to the deadline, before returning no page target found. It returns early with the context error if the caller's context is cancelled, and a Target.getTargets error still returns immediately. The lookup itself moves into findPageTargetID.

Callers:

• SetDeviceMetricsOverride and SetWindowBoundsMaximized (via GetWindowBounds): the display handlers run these under a 10s timeout, so the wait fits inside it.
• DispatchStartURLAndWait: DispatchStartURL already creates a tab if none exists, so the wait normally returns on the first poll.

Tradeoff: when there really is no page target (for example, every tab was closed), the request now fails after about 5s instead of immediately. On the headless path with active recordings, the CDP viewport call is non-fatal, but recordings stay stopped until the handler returns, so the recording gap can grow by up to 5s in that case.

Testing

• Unit tests in lib/cdpclient, with the wait timeout and poll interval made package vars so tests can adjust them:
  • waits for first page target: the fake browser reports no page target for the first three Target.getTargets calls, and the resize succeeds on the fourth. Fails without the fix.
  • no page target: fails with no page target found after the (shortened) timeout. It runs under a context deadline so it fails instead of hanging if the wait is unbounded, and uses a long poll interval so it also covers the deadline clamp.
  • no page target respects context: cancelling the context ends the wait early and returns context.Canceled.
  • Removing the polling, the deadline check, the ctx.Done() case, the clamp, or the %w wrapping each fails at least one of these.
• go test -race ./lib/cdpclient/ and go test ./cmd/api/api/ pass. TestSetDeviceMetricsOverride passed 20 runs under -race, including on 1–2 CPUs with busy-loop processes competing.
• Manual check against a headless image built from main. I closed every page target over CDP and then called PATCH /display with a new size:
  • before the fix: immediate 500 failed to change resolution: CDP setDeviceMetricsOverride: no page target found (the same error CI hits)
  • after the fix, tab reopened 1s after the request started: 200
  • after the fix, no tab at all: 500 ... no page target found after about 5.1s
  • after the fix, ordinary resize: 200, unchanged
• I could not reproduce the startup race naturally on an idle or CPU-limited local Docker host. It appears to need CI-level contention, which is why the manual check forces the no-tab state.
• I did not run the full Docker e2e suite.

---

Note

Medium Risk
Changes timing for display and window CDP operations; worst case adds up to ~5s delay when no tab exists, but reduces startup race flakiness in e2e.

Overview
Fixes intermittent no page target found failures when display resize runs right after Chromium starts or restarts, because DevTools can be reachable before the first tab exists.

firstPageTargetID now polls Target.getTargets every 100ms for up to 5s (timeout and interval are package vars for tests). The one-shot lookup moves to findPageTargetID, which returns an empty ID when there is no page yet; Target.getTargets errors still fail immediately, and the wait honors context cancellation. SetDeviceMetricsOverride, GetWindowBounds / maximize, and DispatchStartURLAndWait all use this path.

Tradeoff: if no page target ever appears, callers fail after ~5s instead of instantly. Unit tests cover delayed targets, timeout, and early cancel via an enhanced fake CDP.

^{Reviewed by Cursor Bugbot for commit 80886dd. Bugbot is set up for automated code reviews on this repo. Configure here.}