Skip to content

Conversation

@majiayu000
Copy link
Contributor

Summary

This PR fixes #399

Changes

  • tool/mcptoolset/set.go
  • tool/mcptoolset/set_test.go

@google-cla
Copy link

google-cla bot commented Dec 30, 2025

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
Copy link
Contributor

Summary of Changes

Hello @majiayu000, 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 resolves an issue where the mcptoolset could encounter 'connection closed' errors due to the reuse of unvalidated, stale cached sessions. By introducing a proactive health check using a Ping mechanism, the system now ensures that only active and valid sessions are utilized, significantly improving connection reliability and preventing unexpected service interruptions.

Highlights

  • Cached Session Validation: Implemented a Ping health check for cached MCP sessions within the getSession method. This validates the session's liveness before reuse.
  • Stale Session Handling: If the Ping check fails, indicating a closed or stale connection, the existing session is now explicitly closed and cleared, forcing a new connection to be established.
  • New Test Case: Added TestSessionValidationOnReuse to set_test.go to verify that cached sessions are correctly validated via Ping before they are reused.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

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
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 correctly addresses an issue where a cached MCP session is not validated, leading to 'connection closed' errors. The fix involves adding a Ping health check before reusing a session and re-establishing the connection if the check fails. The logic is sound. However, the accompanying test only covers the happy path of reusing a valid session. I've suggested adding a new test case to cover the scenario where a session is stale and needs to be recreated, which is the core of this fix.

Comment on lines +311 to +358
// TestSessionValidationOnReuse verifies that the MCP toolset validates
// cached sessions before reuse using Ping health check.
func TestSessionValidationOnReuse(t *testing.T) {
const toolDescription = "returns weather in the given city"

clientTransport, serverTransport := mcp.NewInMemoryTransports()

// Create server instance.
server := mcp.NewServer(&mcp.Implementation{Name: "weather_server", Version: "v1.0.0"}, nil)
mcp.AddTool(server, &mcp.Tool{Name: "get_weather", Description: toolDescription}, weatherFunc)
_, err := server.Connect(t.Context(), serverTransport, nil)
if err != nil {
t.Fatal(err)
}

ts, err := mcptoolset.New(mcptoolset.Config{
Transport: clientTransport,
})
if err != nil {
t.Fatalf("Failed to create MCP tool set: %v", err)
}

readonlyCtx := icontext.NewReadonlyContext(
icontext.NewInvocationContext(
t.Context(),
icontext.InvocationContextParams{},
),
)

// First call should establish a session and return tools.
tools, err := ts.Tools(readonlyCtx)
if err != nil {
t.Fatalf("First Tools() call failed: %v", err)
}
if len(tools) != 1 || tools[0].Name() != "get_weather" {
t.Fatalf("Expected 1 tool named 'get_weather', got %d tools", len(tools))
}

// Second call should reuse the cached session (validated via Ping).
tools2, err := ts.Tools(readonlyCtx)
if err != nil {
t.Fatalf("Second Tools() call failed: %v", err)
}
if len(tools2) != 1 || tools2[0].Name() != "get_weather" {
t.Fatalf("Expected 1 tool named 'get_weather', got %d tools", len(tools2))
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

This test is a good start as it covers the happy path where a cached session is successfully validated and reused. However, it doesn't test the core of the fix, which is handling a stale or closed session.

To ensure the fix is robust, please consider adding another test case that simulates a connection failure. This would involve:

  1. Establishing a session by calling ts.Tools() once.
  2. Closing the connection from the server side. You can capture the server-side session from server.Connect and call Close() on it.
  3. Calling ts.Tools() a second time. This call should detect the stale session via Ping, create a new session, and still succeed.

Here's an example of how you could structure such a test:

func TestStaleSessionIsRecreated(t *testing.T) {
	const toolDescription = "returns weather in the given city"

	clientTransport, serverTransport := mcp.NewInMemoryTransports()

	// Create server instance.
	server := mcp.NewServer(&mcp.Implementation{Name: "weather_server", Version: "v1.0.0"}, nil)
	mcp.AddTool(server, &mcp.Tool{Name: "get_weather", Description: toolDescription}, weatherFunc)

	// Capture the server-side session to be able to close it later.
	serverSession, err := server.Connect(t.Context(), serverTransport, nil)
	if err != nil {
		t.Fatal(err)
	}

	ts, err := mcptoolset.New(mcptoolset.Config{
		Transport: clientTransport,
	})
	if err != nil {
		t.Fatalf("Failed to create MCP tool set: %v", err)
	}

	readonlyCtx := icontext.NewReadonlyContext(
		icontext.NewInvocationContext(
			t.Context(),
			icontext.InvocationContextParams{},
		),
	)

	// First call should establish a session and return tools.
	_, err = ts.Tools(readonlyCtx)
	if err != nil {
		t.Fatalf("First Tools() call failed: %v", err)
	}

	// Simulate connection drop by closing the server-side session.
	if err := serverSession.Close(); err != nil {
		t.Fatalf("Failed to close server session: %v", err)
	}

	// Second call should detect the stale session, reconnect, and succeed.
	tools, err := ts.Tools(readonlyCtx)
	if err != nil {
		t.Fatalf("Second Tools() call failed after session drop: %v", err)
	}
	if len(tools) != 1 || tools[0].Name() != "get_weather" {
		t.Fatalf("Expected 1 tool named 'get_weather' after reconnect, got %d tools", len(tools))
	}
}

@majiayu000 majiayu000 force-pushed the fix-399-mcptoolset-cached-mcp-session--1230-1654 branch from 4d7e35c to 431551d Compare January 1, 2026 03:10
Add session validation using Ping health check before reusing cached
MCP sessions. If the session is stale or closed, it will be automatically
recreated to prevent 'connection closed' errors.

Also adds TestStaleSessionIsRecreated test to verify the fix behavior.
@majiayu000 majiayu000 force-pushed the fix-399-mcptoolset-cached-mcp-session--1230-1654 branch from 431551d to f082621 Compare January 1, 2026 05:30
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.

mcptoolset: cached MCP session not validated, causes "connection closed" errors on subsequent requests

1 participant