Fix flaky TestUpstreamManagerDetectsChromiumAndRestart (raise cold-start timeout)

[rgarcia]

Problem

TestUpstreamManagerDetectsChromiumAndRestart (server/lib/devtoolsproxy/proxy_test.go) fails intermittently in CI (blocking #282):

proxy_test.go: chromium log file contents:
  ...ERROR:dbus/bus.cc:405] Failed to connect to the bus: Could not parse server address...
proxy_test.go: did not detect initial upstream for port 40185; got: ""
--- FAIL: TestUpstreamManagerDetectsChromiumAndRestart (20.15s)

Pre-existing flake on main, independent of #282 (which only touches chromedriverproxy + e2e).

Root cause (corrected after investigation)

The test launches a real headless Chromium and waits for UpstreamManager to scrape the DevTools listening on ws://... line from the browser log. The wait was capped at 20s per launch.

The real cause is Chromium cold-start latency with a long tail on shared CI runners — the wait times out, the line is not missing. Hard evidence:

1. CI duration distribution across recent main runs of this exact test (same /usr/bin/chromium invocation):

Result	Durations
PASS (warm)	6.4s, 6.6s, 6.7s, 6.8s
PASS (slow)	10.1s, 14.3s, 15.4s, 16.96s
FAIL	20.14s, 20.15s, 20.16s

The failures cluster at exactly the 20s timeout — a classic too-tight-deadline signature, with PASS times already creeping to 17s on slow runners.

2. Reproduced with the runner's exact browser. GitHub's ubuntu-latest (24.04) /usr/bin/chromium is a symlink to an open-source Chromium 148.0.7778.0 snapshot build (installed by runner-images from chromium-browser-snapshots; confirmed via the runner-images README + install-google-chrome.sh). I downloaded that exact snapshot and ran the exact test command:

stdbuf -oL -eL <chromium> --headless=new --remote-debugging-address=127.0.0.1 \
  --remote-debugging-port=40185 --no-first-run ... about:blank

Result: the DevTools listening on ws://127.0.0.1:40185/... line is printed reliably (~0.5s warm, 20/20 iterations). So the earlier "this Chromium build never prints the line" theory was wrong.

3. The dbus errors are a red herring. The failure log's dbus/bus.cc:405 Could not parse server address is benign — I reproduced it by setting a malformed DBUS_SESSION_BUS_ADDRESS, and Chromium still printed the DevTools line despite the dbus errors. dbus has nothing to do with CDP/DevTools startup.

So: on a contended runner, the first Chromium launch occasionally takes >20s to bring up its DevTools HTTP server, and the test's 20s waitForCondition expires first.

Fix

• Raise the per-launch detection wait to 60s (named browserDetectTimeout, with the rationale documented) so the slow cold-start tail clears while still failing fast if the browser genuinely never comes up. This is the actual flake fix.
• Secondary hygiene (not the root cause): findBrowserBinary now honors CHROMIUM_BIN/CHROME_BIN and prefers the deterministic chrome/google-chrome binaries, and server-test.yaml pins CHROMIUM_BIN to setup-chrome's chrome-path. This makes the browser-under-test deterministic across runner-image updates; it does not by itself fix the latency flake.

Test output

$ go build ./... && go vet ./lib/devtoolsproxy/      # clean
# run with the EXACT runner Chromium 148.0.7778.0 snapshot:
$ CHROMIUM_BIN=.../chrome-linux/chrome go test ./lib/devtoolsproxy/ -run ...AndRestart -v
--- PASS: TestUpstreamManagerDetectsChromiumAndRestart (1.28s)

Relationship to #282

#282 is blocked only by this pre-existing flake. After this merges, #282 should rebase on main to pick up the timeout + workflow changes and get a green CI run.

🤖 Generated with Claude Code

[rgarcia]

Closing — rolled the real fix (raise the UpstreamManager detect timeout 20s→60s) into #282. The browser-binary pinning (CHROMIUM_BIN + candidate reorder) explored here turned out to be unnecessary: the failure was a too-tight timeout on slow CI runners, not a browser that doesn't emit the DevTools line. #282 carries the timeout change as test(devtoolsproxy): raise UpstreamManager detect timeout 20s -> 60s.