Repository navigation
Bring the live view connect budget inside the embedder watchdog - #472
Open
robertjamesprior wants to merge 1 commit into
Open
robertjamesprior wants to merge 1 commit into
robertjamesprior wants to merge 1 commit into
Conversation
The per-stage connect bounds are sequential, so they sum to a budget an embedder has to outlast to see why a viewer stalled. At 15s + 3s + 30s that budget was 48s, against the 15s mount-to-remount watchdog the live-view docs ship. An embedder following that snippet tears the frame down before a media-stage failure can report its reason, and media is the stage most likely to have stalled. Media drops to 5s. It only has to outlast ICE reaching connected, measured at 1-16ms direct and ~90ms relay-only, so 5s is still a wide ceiling; the stretch is only partly measured because 44 of 130 probe runs stopped at checking. The transport bound stays at 15s, since the live-view proxy can spend ~12s waking a browser before the socket opens and shortening it would report a slow wake as dead. The bounds now sum to 23s, and a test guards that ceiling.
robertjamesprior
marked this pull request as ready for review
October 16, 2026 19:36
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The per-stage connect bounds added in #417 run in sequence, so they sum to a budget an embedder has to outlast to see why a viewer stalled. That budget was 48s (15 + 3 + 30) against the 15s mount-to-remount watchdog in
browsers/live-view.mdx, so an embedder following that snippet throws the frame away before a media-stage failure can report its reason — and media is the stage most likely to have stalled.Media drops from 30s to 5s. The bound only has to outlast ICE reaching
connected, measured at 1-16ms direct and ~90ms relay-only, so 5s is still a wide ceiling. It is a ceiling rather than a calibrated value: 44 of the 130 probe runs stopped atchecking, so the stretch throughconnectedis only partly measured.Transport stays at 15s. The live-view proxy can spend ~12s waking a browser before the socket opens, so shortening it would report a slow wake as dead. Signaling stays at 3s.
The bounds now sum to 23s.
Testing
bun test testsinimages/chromium-headful/client— 231 pass, 0 fail — including a new assertion that the sum of the stage bounds stays at or under 23s, so raising one past the documented watchdog fails a test instead of shipping.tsc --noEmitclean.Related
browsers/live-view.mdxhas to move with this. Its example watchdog is 15s, which is below the sum of the bounds even before this change, and its "the watchdog behind it is cleared once negotiation begins" sentence describes the pre-#417 client. Both are in a docs PR.Note
Medium Risk
Changes WebRTC connect failure timing; a too-tight media bound could surface false timeouts in slow regions, though 5s is still framed as a generous ceiling on ICE-to-connected.
Overview
Lowers the media-stage connect timeout from 30s to 5s so the sequential transport + signaling + media budget (now 23s) can finish before embedders that follow the live-view docs remount (~15s) and never see a
KERNEL_CONNECTION_TIMEOUTwithreason: media.Transport (15s) and signaling (3s) are unchanged. Comments in
CONNECT_STAGE_TIMEOUT_MSnow spell out that stage bounds are a cumulative budget tied to the documented watchdog.A new test asserts the three timeouts sum to ≤ 23s, so raising a stage past the docs watchdog fails CI instead of shipping silently.
Reviewed by Cursor Bugbot for commit 369adc9. Bugbot is set up for automated code reviews on this repo. Configure here.