fix: use server-issued session ID for HTTP backend tools/list

[lpcox]

Problem

HTTP backends that implement the Streamable HTTP MCP transport (spec 2025-03-26) issue a specific Mcp-Session-Id during initialize and require that exact session ID on all subsequent requests. When tools/list arrived with a different session ID, they returned HTTP 400, causing the gateway to register zero tools for the backend — even though the health check reported the server as running.

Root cause: registerToolsFromBackend injected a fabricated "gateway-init-{serverID}" session ID into the request context. In sendHTTPRequest, the context session ID has higher priority than conn.httpSessionID (the real session ID captured from initializeHTTPSession()), so the server-issued ID was silently overridden on every startup-time tools/list call.

Reported in: github/gh-aw#18712 (Datadog MCP server affected)

Fix

Remove the fabricated context session ID from registerToolsFromBackend and pass context.Background() directly. sendHTTPRequest already falls back to conn.httpSessionID when no context session ID is present, so it now correctly uses the server-issued session ID.

// Before
ctx := context.WithValue(context.Background(), SessionIDContextKey, fmt.Sprintf("gateway-init-%s", serverID))
result, err := conn.SendRequestWithServerID(ctx, "tools/list", nil, serverID)

// After
result, err := conn.SendRequestWithServerID(context.Background(), "tools/list", nil, serverID)

Tests

TestHTTPBackendInitialization is rewritten as a regression test for this exact scenario:

• Mock server issues a specific Mcp-Session-Id during initialize
• Mock server rejects tools/list with HTTP 400 if the session ID doesn't match
• Test asserts the gateway uses the server-issued session ID (not a fabricated one)

All existing tests continue to pass.

[Copilot]

Pull request overview

Fixes HTTP backend startup tool discovery by ensuring tools/list uses the server-issued Mcp-Session-Id captured during initialize, rather than overriding it with a gateway-fabricated session ID. This aligns the gateway behavior with strict Streamable HTTP MCP backends (e.g., Datadog) that require the exact session ID they issue.

Changes:

• Remove the fabricated "gateway-init-{serverID}" context session ID from registerToolsFromBackend so sendHTTPRequest falls back to the stored conn.httpSessionID.
• Rewrite TestHTTPBackendInitialization as a regression test asserting tools/list uses the server-issued session ID and fails with HTTP 400 otherwise.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
internal/server/unified.go	Stops injecting a fake session ID into the context for startup-time tools/list, allowing the stored server-issued ID to be used.
internal/server/unified_http_backend_test.go	Updates initialization test to model strict backends that issue/require a specific Mcp-Session-Id, validating the regression scenario.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The mock server handler doesn’t send any response for unexpected JSON-RPC methods (falls through the switch), which results in a 200 with an empty body. That can make failures hard to diagnose if startup behavior changes (e.g., additional methods during init). Consider adding a default case that returns a JSON-RPC error / HTTP 400 (or calls t.Errorf) so unexpected methods fail fast.

Suggested change

	})
	})
	default:
	// Fail fast on unexpected JSON-RPC methods so tests are easier to diagnose.
	t.Errorf("unexpected JSON-RPC method %q", req.Method)
	w.WriteHeader(http.StatusBadRequest)
	w.Header().Set("Content-Type", "application/json")
	_ = json.NewEncoder(w).Encode(map[string]interface{}{
	"jsonrpc": "2.0",
	"error": map[string]interface{}{"code": -32601, "message": "Unexpected method"},
	"id": 1,
	})

[Copilot]

toolsListSessionID is written from the httptest server handler goroutine and read from the main test goroutine without synchronization. This will trigger the Go race detector and can be flaky. Consider capturing the session ID via a buffered channel, sync.Mutex, or atomic.Value and reading it after NewUnified completes.