fix(cli): forward termination signals to relaunched child process#25642
fix(cli): forward termination signals to relaunched child process#25642ixchio wants to merge 1 commit intogoogle-gemini:mainfrom
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses an issue where child processes spawned by the CLI become orphaned when the parent process is terminated. By explicitly forwarding termination signals and ensuring proper cleanup of event listeners, the changes ensure that the child process lifecycle is correctly tied to the parent, improving stability in containerized and automated environments. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request implements signal forwarding from the parent process to the child process in relaunchAppInChildProcess to prevent orphaned processes, including listener cleanup and improved IPC error handling. Feedback suggests removing the !child.killed guard to allow for signal escalation (e.g., sending SIGTERM after SIGINT) and reordering the message listener registration to ensure it is active before the initial child.send() call. The test suite should also be updated to reflect these logic improvements.
When relaunchAppInChildProcess spawns a child, it doesn't forward SIGTERM, SIGHUP, or SIGINT. If the parent gets killed by a process manager or via kill(pid), the child becomes an orphan — particularly problematic in containers and ACP deployments. This installs signal forwarders right after spawn() and cleans them up on close/error. The child.send() call is wrapped in try/catch so a dead IPC channel doesn't leak handlers. Fixes google-gemini#25590
3e50ea2 to
146fb5a
Compare
This one's been bugging me — when you kill the parent process, the child just... keeps running.
The problem
relaunchAppInChildProcessspawns a child but never forwardsSIGTERM,SIGHUP, orSIGINT. So if a process manager (or justkill <pid>) sends a signal to the parent, the child becomes an orphan. Pretty annoying in containers and ACP setups.What I did
spawn()forSIGTERM,SIGHUP, andSIGINTchild.killedbefore forwarding (no point sending signals to a dead process)closeanderroreventschild.send()in try/catch — if the IPC channel is already dead when we try to send admin settings, we don't want that to leak the signal handlersWhy not PR #25605?
That PR had a couple issues the reviewers flagged:
!process.stdin.isTTYcheck that re-introduces the leak for programmatickill -INTchild.send()throws before promise setupThis PR forwards unconditionally and handles the cleanup properly.
Tests
Added 4 tests:
Fixes #25590
cc @scidomino @jacob314 would love your eyes on this