[tnsardesai]

Summary

Right after Chromium starts, PUT /browser/location can fail with browser location components have not converged. This happens most often when a profile restores a saved tab that loads slowly.

A Chromium that has just started does not react when /etc/localtime is replaced, so the location's timezone never converges. Each reconcile round replaces the file again, about every 1.55s. Chromium reacts to the first replacement it sees after it finishes starting, and the location converges a few milliseconds later. When a profile restores a slow tab, startup can take longer than the 5s apply deadline. The reconcile then gives up just before Chromium would have seen the next replacement.

The timeout is now split in two:

• browserLocationApplyTimeout (5s, unchanged) is how long an attempt has to converge.
• browserLocationStartupTimeout (10s, new) is how long Chromium has, counted from when its DevTools endpoint comes up, before it is expected to notice the timezone file being replaced.

An attempt now stops at whichever of the two ends later. A Chromium that has finished starting still gets exactly 5s. waitBrowserLocationApplied uses the same deadline. To support this, UpstreamManager.Since() records when the current DevTools URL was discovered, in wall-clock time.

When a location fails to converge, the error log now includes the component status, so a prod failure shows which component is stuck.

Repro (prod image, profile whose saved tab is https://httpbin.org/delay/9)

I polled GET /browser/location inside the VM while sending PUT /browser/location about 1.5s after Chromium came up:

t after PUT	components
95ms	browser and network converged, 5 renderers pending, timezone not converged
4090ms	renderers ack after their 4s timezone wait, timezone still not converged
4774ms	timezone converged. This is right after the reconcile's fourth replacement of /etc/localtime, at about 4.65s

The PUT returned 200 after 4.7s, just inside the 5s deadline. One in six creates with this profile plus location failed in prod. The same PUT sent to the same browser 12s after start converged in 30ms.

Testing

• TestSetBrowserLocationWaitsForStartingChromiumToObserveTimezone reproduces the bug with a fake Chromium that ignores timezone file replacements until 5.5s after it starts. It fails on main with a 500 after 5s and passes with this change.
• TestBrowserLocationDeadline covers the deadline for an unknown Chromium, a settled one and a starting one.
• go test -race ./cmd/api/api/ -run 'BrowserLocation|Reapply' and go test ./cmd/api/... ./lib/devtoolsproxy/... pass. go vet is clean.
• I did not build an image or run the e2e tests.

Notes

• A location sent within 10s of Chromium starting can now take up to about 9s to fail instead of 5s. Calls that succeed are not slowed down.
• When the image API process restarts, it reads the existing Chromium log again, so Since() is reset to the restart time. A failing location sent in the next 10s waits longer than it needs to before it fails.
• The Kernel API's own wait for the image is 10s. A companion change raises it so a create that lands right after a Chromium restart does not time out first. That change should ship before this one.

[tnsardesai]

Closing in favor of applying the location before the configure restart, so it no longer depends on Chromium startup time.