v1.40.0.2 fix(browse): Cmd+Q on managed Chromium stops triggering supervisor respawn#1626
Open
garrytan wants to merge 1 commit into
Open
v1.40.0.2 fix(browse): Cmd+Q on managed Chromium stops triggering supervisor respawn#1626garrytan wants to merge 1 commit into
garrytan wants to merge 1 commit into
Conversation
…ervisor respawn
Three browser.on('disconnected') handlers in browse/src/browser-manager.ts
(launch, launchHeaded, handoff) each exited with a non-zero code on every
disconnect, regardless of cause. Process supervisors that consume our exit
code (gbrowser's gbd HealthMonitor in cmd/gbd/health.go) treated user
Cmd+Q identical to a Chromium crash and respawned with exponential
backoff, so the visible browser kept reappearing after the user closed it.
Add resolveDisconnectCause(browser) that reads the underlying ChildProcess
exitCode + signalCode (waiting up to 1s for the exit event if the
disconnected event fired first). Exit code 0 + no signal = clean user
quit; anything else = crash, signal-kill, or OOM.
Wire the resolver into all three disconnect handlers:
- launch() (headless): clean → exit 0, crash → exit 1 (was always 1)
- launchHeaded() (headed): clean → exit 0, crash → exit 2 (was always 2)
onDisconnect() cleanup callback still runs in both cases.
- handoff() (re-launch): same as launch() via the helper.
Preserve the per-path crash codes (1 vs 2) so any supervisor that
differentiated headed vs headless crashes keeps working.
Seven new unit tests in browse-manager-unit.test.ts cover the resolver
across already-exited, signal-killed (SIGSEGV / SIGKILL), async exits,
and null-browser inputs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 20, 2026
Owner
Author
|
Bundled into #1629 as the v1.42.1.1 fix wave, along with PR #1617 and an additional exit-code propagation fix that Codex caught: this PR's Leaving this PR open until #1629 merges so we have a working fallback. Will close with a final "merged via #1629" once landed. |
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
Three `browser.on('disconnected')` handlers in `browse/src/browser-manager.ts` exited with non-zero codes for every disconnect — including user-initiated Cmd+Q. Process supervisors that consume our exit code (gbrowser's `gbd` HealthMonitor) treated this as a crash and respawned the whole stack on exponential backoff. Result: user closes the browser, window pops back 1s later, then 2s, then 4s.
This PR adds `resolveDisconnectCause(browser)` that reads the underlying ChildProcess's `exitCode` + `signalCode` (waiting up to 1s for the exit event if `disconnected` fires first). The three handlers consume it:
Crash-recovery is preserved: SIGSEGV / SIGKILL / OOM / non-zero exits all still exit non-zero and supervisors restart with backoff. Only the clean Cmd+Q path is new.
Test plan
Related
🤖 Generated with Claude Code