Skip to content

fix(core): prevent unhandled promise rejection on IDE MCP fetch failure#26484

Open
SAY-5 wants to merge 1 commit intogoogle-gemini:mainfrom
SAY-5:fix/terminal-error-25751
Open

fix(core): prevent unhandled promise rejection on IDE MCP fetch failure#26484
SAY-5 wants to merge 1 commit intogoogle-gemini:mainfrom
SAY-5:fix/terminal-error-25751

Conversation

@SAY-5
Copy link
Copy Markdown

@SAY-5 SAY-5 commented May 5, 2026

Summary

Register the MCP client's transport-level onerror/onclose handlers before calling client.connect(transport) so that fetch failures from the streamable-HTTP SSE listener are routed through the client's error handler instead of escaping as unhandled promise rejections.

Details

Issue #25751 reports a CRITICAL: Unhandled Promise Rejection! with TypeError: fetch failed whose cause is undici's HeadersTimeoutError (UND_ERR_HEADERS_TIMEOUT). The fetch in question is the long-lived SSE listening request opened by StreamableHTTPClientTransport against the local IDE companion at http://127.0.0.1:<port>/mcp. When that stream's headers timer fires (e.g. the IDE companion stops responding), the rejection bubbles up through undici with no .catch in the chain.

In ide-client.ts, the existing registerClientHandlers() was called after await client.connect(transport). That left a window — covering both the connect handshake and any post-connect SSE failure routed via transport.onerror — in which the client had no onerror/onclose defined, so the SDK had nowhere to forward the failure.

This change splits handler registration in two:

  • registerTransportHandlers(): assigns client.onerror / client.onclose, invoked before client.connect(transport). These map to transport-level errors and route them through setState(Disconnected, ...).
  • registerClientHandlers(): registers the notification handlers (which require an active session), invoked after connect, as before.

Both establishHttpConnection and establishStdioConnection call the new helper before connect.

Related Issues

Fixes #25751

How to Validate

  1. Start the gemini-cli with /ide enable connected to a VS Code companion extension.
  2. Stop responding from the IDE side (e.g. suspend the extension host) so the SSE stream stalls beyond undici's headers timeout.
  3. Before this change: a CRITICAL: Unhandled Promise Rejection! panel is rendered with TypeError: fetch failed / HeadersTimeoutError.
  4. After this change: the IDE connection state transitions to Disconnected with the standard "IDE connection error" message and the user is prompted to run /ide enable to reconnect.

Pre-Merge Checklist

  • Updated relevant documentation and README (if needed)
  • Added/updated tests (if needed)
  • Noted breaking changes (if any)
  • Validated on required platforms/methods:
    • MacOS
      • npm run

Register transport onerror/onclose handlers before calling client.connect
so that fetch failures during the streamable-HTTP SSE listener (e.g.
undici HeadersTimeoutError on a stalled IDE companion) are routed
through the client's error handler instead of escaping as unhandled
promise rejections.

Fixes google-gemini#25751

Signed-off-by: SAY-5 <say.apm35@gmail.com>
@SAY-5 SAY-5 requested a review from a team as a code owner May 5, 2026 03:26
@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, 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 IDE connection failures resulted in unhandled promise rejections. By reordering the initialization sequence to register transport-level error and close handlers before the client connection is established, the system can now gracefully capture and route connection-related errors through the existing state management logic.

Highlights

  • Transport Handler Registration: Split the handler registration logic into two distinct phases: transport-level handlers and client-level notification handlers.
  • Error Handling Improvement: Invoked transport handlers before client connection to ensure that connection-related errors and SSE stream failures are properly caught, preventing unhandled promise rejections.
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.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the IdeClient to separate transport-level error handling from application-level notification handlers. It introduces registerTransportHandlers to be called before the client connects, ensuring that connection errors and SSE stream issues are properly captured. I have provided feedback regarding a potential race condition where notifications might be missed if handlers are registered after the connection is established, and a suggestion to improve error logging by capturing the actual error message instead of a static string.

},
);
this.client.onerror = (_error) => {
const errorMessage = _error instanceof Error ? _error.message : `_error`;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The fallback value _error is currently a string literal, which prevents detailed error logging. It should be updated to capture the actual error details for debugging. Additionally, ensure the resulting string is trimmed and falls back to a non-empty default to avoid uninformative messages from whitespace-only strings.

Suggested change
const errorMessage = _error instanceof Error ? _error.message : `_error`;
const errorMessage = (_error instanceof Error ? _error.message : String(_error)).trim() || "Unknown error";
References
  1. When catching exceptions, log the detailed error for debugging instead of providing only a generic error message.
  2. When using an optional string with a fallback value, trim the optional string and use the fallback if the result is empty to avoid uninformative messages from whitespace-only strings.

};
}

private registerClientHandlers() {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Registering handlers after connection introduces a race condition where early notifications might be missed. Since the MCP SDK allows registering handlers before connection, moving registerClientHandlers() before client.connect(transport) ensures the startup sequence correctly handles incoming messages without needing additional state management for race conditions.

References
  1. Avoid redundant internal state management for race conditions if the application's startup sequence already guarantees the correct order of operations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Error in Terminal

1 participant