Fix: Aborted Task and Closed Agent

[shahyashish]

The issue was caused by an internal AbortError (likely triggered by loop recovery in GeminiClient) surfacing as an unhandled rejection or uncaught exception, which then caused the agent to crash or show a scary stack trace.

The fix involved updating setupUnhandledRejectionHandler in packages/cli/src/gemini.tsx to:

1. Use a more robust check for AbortError by checking reason?.name === 'AbortError'. This is safer than instanceof Error because in bundled environments or different Node versions (where AbortError might be a DOMException), the instanceof check can fail.
2. Add a listener for uncaughtException to handle cases where the error isn't caught by promise rejection logic, which prevents the Node.js process from exiting unexpectedly (the 'Closed Agent' part of the issue).
3. Keep the suppression silent (logging only to debugLogger.log) to prevent transient internal recovery state changes from being displayed to the user as fatal errors.

Test: To verify the fix:

1. Run the Gemini CLI in interactive mode with an image input that might trigger a complex or long-running task.
2. If the internal client triggers a loop recovery (calling abort()), ensure that no AbortError stack trace appears on the screen and the CLI session remains active (instead of closing the agent).
3. You can also manually trigger an unhandled AbortError rejection in a development build and verify it is caught silently by checking the debug logs, while a non-AbortError still triggers the 'CRITICAL' error message and opens the debug console.

[google-cla]

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.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 stability issues in the Gemini CLI where internal AbortErrors, often triggered during loop recovery, were causing the agent to crash or display intrusive stack traces. By centralizing error handling and improving the robustness of error identification, the changes ensure that these transient events are handled silently without interrupting the user session.

Highlights

• Robust AbortError Handling: Updated the error detection logic to use a property check (reason?.name === 'AbortError') instead of instanceof, ensuring compatibility across different environments and Node versions.
• Uncaught Exception Prevention: Added a listener for uncaughtException to prevent the Node.js process from crashing unexpectedly when internal errors occur.
• Centralized Error Logic: Refactored error handling into a shared handleError function to ensure consistent suppression of transient AbortErrors across both unhandled rejections and uncaught exceptions.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the error handling in gemini.tsx by introducing a shared handleError function for unhandledRejection and uncaughtException events. The main change involves adding a handler for uncaughtException to prevent process crashes. However, a critical issue was identified: the current uncaughtException handling does not terminate the process for non-AbortError exceptions, which can lead to an unstable application state. A suggestion was provided to ensure proper cleanup and process termination for all non-AbortError uncaught exceptions, aligning with Node.js best practices. There is also a minor formatting change in the main function.

[gemini-code-assist]

While handling uncaughtException prevents the process from crashing for AbortError, it's very risky to resume normal operation for other types of uncaught exceptions. According to the Node.js documentation, an uncaught exception leaves the application in an undefined state, and continuing to run can lead to unpredictable behavior, memory leaks, or data corruption.

The recommended practice is to perform cleanup and then terminate the process. For AbortError, the current logic of suppressing it is correct, but for all other errors, the process should exit gracefully to ensure stability.

  process.on('uncaughtException', async (error) => {
    // Suppress expected AbortErrors, which are not fatal.
    if (error?.name === 'AbortError') {
      handleError(error);
      return;
    }

    // For any other uncaught exception, the application is in an undefined state.
    // It is not safe to continue. Log the error, attempt cleanup, and exit.
    handleError(error);

    // The Node.js documentation strongly advises against resuming normal
    // operation after an 'uncaughtException'. The process must terminate.
    await runExitCleanup();
    process.exit(1);
  });