client/transport/streamable_http.go (1)

202-210: ⚠️ Potential issue

Guard against double-closing initialized channel

close(c.initialized) is executed each time an initialize request succeeds.
A second initialize (or a retry after a transient 50x) will panic because a closed
channel cannot be closed again.

-       close(c.initialized)
+       // close only once
+       select {
+       case <-c.initialized: // already closed – nothing to do
+       default:
+               close(c.initialized)
+       }

client/transport/streamable_http.go (3)

258-266: Avoid setting Content-Type on GET requests

The Content-Type header is meaningless (and sometimes confusing for proxies)
when the request has no body. It is safer to omit it for GET.

- req.Header.Set("Content-Type", "application/json")
+ if method != http.MethodGet {
+     req.Header.Set("Content-Type", "application/json")
+ }

---

469-476: resp.Body is closed twice

createGETConnectionToServer defers resp.Body.Close() and passes the same
reader to handleSSEResponse, which in turn closes it in readSSE. A double
close is harmless but unnecessary and can mislead future maintainers.

- defer resp.Body.Close()
+ // readSSE will close resp.Body for us

---

57-61: Nil-logger safety

WithLogger directly assigns the provided logger. If a caller passes nil
the transport will panic on first call. Either document the contract or add a
nil-fallback:

return func(sc *StreamableHTTP) {
-       sc.logger = logger
+       if logger != nil {
+               sc.logger = logger
+       }
}

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge Base: Disabled due to data retention organization setting

client/transport/streamable_http.go (1)

292-295: Differentiate 404 "session terminated" from generic 404

Blindly treating every 404 as "session terminated" can hide genuine endpoint-routing issues. Consider checking a sentinel header or body message returned by the server before wiping the session id.

client/transport/streamable_http.go (4)

445-466: Consider specific handling for session termination in listenForever

The listenForever method doesn't specifically check for the errSessionTerminated error, which might lead to unnecessary retries when the session is actually terminated.

func (c *StreamableHTTP) listenForever() {
	c.logger.Infof("listening to server forever")
	for {
		err := c.createGETConnectionToServer()
		if errors.Is(err, errGetMethodNotAllowed) {
			// server does not support listening
			c.logger.Errorf("server does not support listening")
			return
		}
+		if errors.Is(err, errSessionTerminated) {
+			// Session was terminated, no need to retry until reinitialization
+			c.logger.Errorf("session terminated, waiting for reinitialization")
+			// Wait for reinitialization signal
+			select {
+			case <-c.closed:
+				return
+			case <-c.initialized: // This would require resetting and recreating this channel on reinitialization
+				c.logger.Infof("session reinitialized, resuming listening")
+				continue
+			}
+		}

		select {
		case <-c.closed:
			return
		default:
		}

		if err != nil {
			c.logger.Errorf("failed to listen to server. retry in 1 second: %v", err)
		}
		time.Sleep(retryInterval)
	}
}

---

472-473: Consider making retryInterval configurable

The retryInterval variable is used for testing convenience, but it's not exposed for configuration. Consider making it configurable via an option function to allow users to adjust the retry behavior.

+// WithRetryInterval sets the interval between retries for continuous listening.
+func WithRetryInterval(interval time.Duration) StreamableHTTPCOption {
+	return func(sc *StreamableHTTP) {
+		sc.retryInterval = interval
+	}
+}

type StreamableHTTP struct {
	baseURL             *url.URL
	httpClient          *http.Client
	headers             map[string]string
	headerFunc          HTTPHeaderFunc
	logger              util.Logger
	getListeningEnabled bool
+	retryInterval       time.Duration

	initialized chan struct{}
	sessionID   atomic.Value // string

	notificationHandler func(mcp.JSONRPCNotification)
	notifyMu            sync.RWMutex

	closed chan struct{}
}

// In NewStreamableHTTP
smc := &StreamableHTTP{
	baseURL:      parsedURL,
	httpClient:   &http.Client{},
	headers:      make(map[string]string),
	closed:       make(chan struct{}),
	logger:       util.DefaultLogger(),
	initialized:  make(chan struct{}),
+	retryInterval: 1 * time.Second,
}

// In listenForever
time.Sleep(c.retryInterval)

---

477-478: Consider using a context with timeout for GET requests

The code creates a background context without timeout for GET requests. Consider using a context with timeout to prevent overly long-running requests if there are network issues.

-ctx := context.Background() // the sendHTTP will be automatically canceled when the client is closed
+ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) // adjust timeout as needed
+defer cancel() // ensure resources are cleaned up
resp, err := c.sendHTTP(ctx, http.MethodGet, nil, "text/event-stream")

---

151-158: Use logger instead of fmt.Printf for error messages

There are several instances of fmt.Printf in the code that should be replaced with the logger for consistency. This includes lines 151, 157, 321, 329, and 382.

-fmt.Printf("failed to create close request\n: %v", err)
+c.logger.Errorf("failed to create close request: %v", err)

-fmt.Printf("failed to send close request\n: %v", err)
+c.logger.Errorf("failed to send close request: %v", err)

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge Base: Disabled due to data retention organization setting

client/transport/streamable_http.go (1)

284-354: Addresses previous 404 handling concern with improved logic

The sendHTTP method centralizes request handling and addresses the previous review comment about 404 handling. The universal 404 handling clears session ID, but the caller (SendRequest) has special logic for initialization requests to distinguish routing issues from session termination.

client/transport/streamable_http.go (2)

347-351: Session ID race condition in CompareAndSwap

The CompareAndSwap operation could fail if the session ID changed between reading it (line 312) and this comparison, potentially leaving a stale session ID. Consider using a more robust approach.

 	// universal handling for session terminated
 	if resp.StatusCode == http.StatusNotFound {
-		c.sessionID.CompareAndSwap(sessionID, "")
+		c.sessionID.Store("")
 		return nil, errSessionTerminated
 	}

---

548-579: Consider context handling in long-lived connection

Using context.Background() means the GET connection won't be canceled by request-specific contexts, which is appropriate for a long-lived listening connection. However, consider if this could lead to resource leaks.

The comment on line 550 could be more specific:

-	ctx := context.Background() // the sendHTTP will be automatically canceled when the client is closed
+	ctx := context.Background() // sendHTTP will cancel when client.closed is triggered

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

client/transport/streamable_http.go (1)

385-386: 🛠️ Refactor suggestion

Inconsistent error logging - use structured logger.

Several locations use fmt.Printf for error logging instead of the configured logger, which bypasses the logging infrastructure.

Replace fmt.Printf calls with the structured logger:

-			fmt.Printf("failed to unmarshal message: %v\n", err)
+			c.logger.Errorf("failed to unmarshal message: %v", err)

-				fmt.Printf("failed to unmarshal notification: %v\n", err)
+				c.logger.Errorf("failed to unmarshal notification: %v", err)

-					fmt.Printf("SSE stream error: %v\n", err)
+					c.logger.Errorf("SSE stream error: %v", err)

Also applies to: 393-394, 446-447

client/transport/streamable_http.go (2)

292-362: Excellent refactoring with minor context leak concern.

The sendHTTP method effectively consolidates HTTP request logic, eliminating duplication. However, there's a potential goroutine leak in the context cancellation logic.

In lines 301-308, the goroutine for context cancellation may not be cleaned up if the HTTP request completes quickly. Consider this pattern instead:

-	go func() {
-		select {
-		case <-c.closed:
-			cancel()
-		case <-newCtx.Done():
-			// The original context was canceled, no need to do anything
-		}
-	}()
+	go func() {
+		defer cancel()
+		select {
+		case <-c.closed:
+		case <-newCtx.Done():
+		}
+	}()

This ensures the cancel function is always called, cleaning up resources properly.

---

549-554: Consider making retry interval configurable.

The hardcoded 1-second retry interval may not be suitable for all deployment scenarios.

Consider adding a configuration option for the retry interval:

+func WithRetryInterval(interval time.Duration) StreamableHTTPCOption {
+	return func(sc *StreamableHTTP) {
+		sc.retryInterval = interval
+	}
+}

And add a retryInterval field to the struct with a default value.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

client/transport/streamable_http.go (2)

230-241: ⚠️ Potential issue

Ensure initialized channel is closed on all initialization paths

While sync.Once prevents double-closing, the channel is only closed on successful initialization. If the initialize request fails (e.g., error from sendHTTP or non-OK status), the listening goroutine will block indefinitely.

Consider closing the channel in a defer or ensuring it's closed on error paths:

 func (c *StreamableHTTP) SendRequest(
 	ctx context.Context,
 	request JSONRPCRequest,
 ) (*JSONRPCResponse, error) {
+	// Ensure initialized is closed for initialize requests
+	if request.Method == string(mcp.MethodInitialize) {
+		defer c.initializedOnce.Do(func() {
+			close(c.initialized)
+		})
+	}
 
 	// Marshal request
 	requestBody, err := json.Marshal(request)

Also applies to: 264-274

---

354-357: 🛠️ Refactor suggestion

Differentiate session termination from routing errors

The code still treats every 404 as session termination, which could mask genuine endpoint routing issues. Consider checking for a sentinel header or specific response body to confirm session termination.

 // universal handling for session terminated
 if resp.StatusCode == http.StatusNotFound {
-    c.sessionID.CompareAndSwap(sessionID, "")
-    return nil, errSessionTerminated
+    // Check if this is actually a session termination
+    if resp.Header.Get("X-Session-Terminated") == "true" {
+        c.sessionID.CompareAndSwap(sessionID, "")
+        return nil, errSessionTerminated
+    }
+    // Otherwise, let the caller handle the 404
 }

client/transport/streamable_http.go (1)

592-604: Consider goroutine lifecycle for frequent calls

While this helper ensures proper cancellation, each call spawns a goroutine that lives until context cancellation. For high-frequency operations, consider reusing a single monitoring goroutine or using context.WithCancelCause.

client/http_test.go (2)

85-192: Comprehensive test coverage for continuous listening

The tests effectively verify both the default behavior and the continuous listening feature. The subtest structure improves readability and test isolation.

Consider using a helper function to wait for notifications with timeout instead of fixed sleep durations:

func waitForNotifications(t *testing.T, notificationNum *SafeMap, method string, expected int, timeout time.Duration) {
    deadline := time.Now().Add(timeout)
    for time.Now().Before(deadline) {
        if notificationNum.Get(method) == expected {
            return
        }
        time.Sleep(10 * time.Millisecond)
    }
    t.Errorf("Timeout waiting for %d %s notifications, got %d", expected, method, notificationNum.Get(method))
}

---

15-16: Remove or complete the incomplete comment

The comment for SafeMap is incomplete and should be either finished or removed.

-// SafeMap is a thread-safe map wrapper
-
+// SafeMap is a thread-safe map wrapper for counting notifications

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

client/http_test.go (1)

122-122: Fix typo in error messages.

There's a typo "progross" that should be "progress" in the error messages.

-				t.Errorf("Expected 1 progross notification item, got %d", n)
+				t.Errorf("Expected 1 progress notification item, got %d", n)

And similarly on line 176:

-				t.Errorf("Expected 1 progross notification item, got %d", n)
+				t.Errorf("Expected 1 progress notification item, got %d", n)

Also applies to: 176-176

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

client/transport/streamable_http.go (1)

385-385: Replace print statements with structured logging

These print statements should use the logger for consistency with the rest of the codebase.

-				fmt.Printf("failed to unmarshal message: %v\n", err)
+				c.logger.Errorf("failed to unmarshal message: %v", err)

-					fmt.Printf("failed to unmarshal notification: %v\n", err)
+					c.logger.Errorf("failed to unmarshal notification: %v", err)

-					fmt.Printf("SSE stream error: %v\n", err)
+					c.logger.Errorf("SSE stream error: %v", err)

Also applies to: 393-393, 446-446

client/transport/streamable_http.go (1)

583-583: Response from handleSSEResponse is ignored

The return value from handleSSEResponse is ignored, but this may be intentional for the continuous listening use case where we don't expect a specific response.

However, consider logging if an unexpected response is received to aid in debugging:

-	_, err = c.handleSSEResponse(ctx, resp.Body)
+	response, err := c.handleSSEResponse(ctx, resp.Body)
+	if response != nil {
+		c.logger.Warnf("unexpected response received during continuous listening: %v", response)
+	}

client/transport/streamable_http.go (1)

529-550: Robust continuous listening implementation

The listenForever method handles server capabilities properly by detecting when GET method is not allowed. The retry logic with exponential backoff would be more robust than a fixed 1-second interval.

Consider implementing exponential backoff for retries:

+var maxRetryInterval = 30 * time.Second
+
 func (c *StreamableHTTP) listenForever(ctx context.Context) {
 	c.logger.Infof("listening to server forever")
+	currentRetryInterval := retryInterval
 	for {
 		err := c.createGETConnectionToServer(ctx)
 		if errors.Is(err, errGetMethodNotAllowed) {
 			c.logger.Errorf("server does not support listening")
 			return
 		}
 
 		select {
 		case <-ctx.Done():
 			return
 		default:
 		}
 
 		if err != nil {
 			c.logger.Errorf("failed to listen to server. retry in %v: %v", currentRetryInterval, err)
+			time.Sleep(currentRetryInterval)
+			currentRetryInterval = min(currentRetryInterval*2, maxRetryInterval)
+		} else {
+			currentRetryInterval = retryInterval // reset on success
-		}
-		time.Sleep(retryInterval)
+		}
 	}
 }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: leavez
PR: mark3labs/mcp-go#114
File: client/transport/sse.go:137-179
Timestamp: 2025-04-06T10:07:06.685Z
Learning: The SSE client implementation in the MCP-Go project uses a 30-second timeout for reading SSE events to match the behavior of the original implementation before the transport layer refactoring.

Learnt from: davidleitw
PR: mark3labs/mcp-go#451
File: mcp/tools.go:1192-1217
Timestamp: 2025-06-26T09:38:18.629Z
Learning: In mcp-go project, the maintainer prefers keeping builder pattern APIs simple without excessive validation for edge cases. The WithOutput* functions are designed to assume correct usage rather than defensive programming, following the principle of API simplicity over comprehensive validation.

client/transport/streamable_http.go (1)

356-359: Generic 404 handling may mask routing issues

The current implementation treats all 404 responses as session termination, which could hide genuine endpoint routing problems. Consider checking for specific headers or response body content that confirms session termination.

client/transport/streamable_http.go (1)

586-591: Address specification ambiguity with GET responses

The comment explains a potential compatibility issue where other SDKs might send response messages via the GET connection. Consider implementing a mechanism to handle these responses or provide a configuration option for different compatibility modes.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: leavez
PR: mark3labs/mcp-go#114
File: client/transport/sse.go:137-179
Timestamp: 2025-04-06T10:07:06.685Z
Learning: The SSE client implementation in the MCP-Go project uses a 30-second timeout for reading SSE events to match the behavior of the original implementation before the transport layer refactoring.

Learnt from: leavez
PR: mark3labs/mcp-go#114
File: client/transport/sse.go:137-179
Timestamp: 2025-04-06T10:07:06.685Z
Learning: The SSE client implementation in the MCP-Go project uses a 30-second timeout for reading SSE events to match the behavior of the original implementation before the transport layer refactoring.

Learnt from: davidleitw
PR: mark3labs/mcp-go#451
File: mcp/tools.go:1192-1217
Timestamp: 2025-06-26T09:38:18.629Z
Learning: In mcp-go project, the maintainer prefers keeping builder pattern APIs simple without excessive validation for edge cases. The WithOutput* functions are designed to assume correct usage rather than defensive programming, following the principle of API simplicity over comprehensive validation.