fix(browser): serve waits for chrome, keeps its stderr, and reaps its own Xvfb (DIVE-4400) - #67
Open
5dive-bot wants to merge 1 commit into
Open
fix(browser): serve waits for chrome, keeps its stderr, and reaps its own Xvfb (DIVE-4400)#675dive-bot wants to merge 1 commit into
5dive-bot wants to merge 1 commit into
Conversation
… own Xvfb (DIVE-4400) `serve` backgrounded chrome with `>/dev/null 2>&1 &`, wrote chrome_pid=$! unconditionally and printed success. A chrome that trapped in its first millisecond was therefore indistinguishable from a healthy one to `ls`, to the stack row and to `viewer` — and the only surface that told the truth was the customer's Connect press, which 502'd. - _pid_live: a reaped-pending zombie answers `kill -0` with success, so the one moment we need the truth is the one moment kill -0 cannot give it. /proc says Z. - serve waits, bounded, for the process to still exist before writing a pidfile or printing anything; on death it dies E_UNAVAILABLE carrying chrome's own stderr (kept in the profile at 0600 instead of discarded). - a failed serve reaps the Xvfb it started, so it leaves no orphan display for _display_free to hop past forever. - _probe's "UNKNOWN (probe did not load)" now names what chrome said and STAMPS the profile, so `ls` can tell it from "never probed". Tests: tests/browser_plugin_unit.sh T10u — control arm (a chrome that stays up still serves, its Xvfb left running), then the defect: rc 69, no success line, chrome's two stderr lines handed back, no pidfile, Xvfb reaped, and the dashboard's own `viewer` call refusing. 208 passed / 0 failed. Mutants: dropping the reap fails exactly the orphan arm; restoring the old print-and-return shape fails six. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
2 participants
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.
DIVE-4400 arm 1 —
servemust not print success until Chrome is aliveMeasured on our canary (exact-swallow, 2026-09-13 04:0x–04:2xZ):
5dive browser serve linkedin.comprintedserving linkedin.com on :375 (persistent …)and left no Chrome process atall — only the Xvfb it started.
browser lslisted the site, the stack statusread
state=ok / store=ready, and the only surface that told the truth was acustomer pressing Connect on the live dashboard and getting a 502.
bin/browserbackgrounded Chrome with>/dev/null 2>&1 &, wrotechrome_pid=$!unconditionally, printed success, and judged liveness by theXvfb pid. A Chrome that dies in the first millisecond was indistinguishable
from a healthy one, and its stderr was discarded before anyone could read it.
This PR
servewaits for the pid,kill -0s it after a beat, and on failure exitsnon-zero with Chrome's own stderr (no longer sent to
/dev/null).servereaps the Xvfb it started, so it no longer leaves anorphan display that pushes the next
_display_freeprobe to:376,:377, …(two such orphans were standing on the canary).
Evidence
tests/browser_plugin_unit.sh— 208 passed / 0 failed (199 before, +9 arms).Mutants, anchored to individual arms:
T10u …and REAPS THE Xvfb it startedline, both stderr lines, the pidfile, the reap)
Controls, because a negative arm that cannot fail is arm-counting: T10u first
runs a Chrome that stays up on the same rig and asserts
servesucceeds andits Xvfb is left running. The fake Xvfb records its own pid (
execkeepsit) — "no display was left behind" cannot be read off the product's pidfile,
because a correct failure deletes that file.
Not claimed
Not re-measured on the canary: that box's Chrome is still broken (a
libc6upgrade pending reboot — the trigger, not the defect) and this host has no
browser stack installed. The on-box re-measure —
serverefusing, the rowreading degraded, Connect still 502 but now visibly — is owed and is the
real acceptance for DIVE-4355.
Arm 2 (the stack health row) is 5dive-ai/5dive-api's companion PR.
🤖 Generated with Claude Code