mcp: ClientSession.ReadResource keeps uncacheable and expired results until the session ends

Abierto
  • ¿Algo no está bien?
#1,526 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

  • #1527 de @Assertive-xxh — cerrado sin fusionar

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
74/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
backend, performance

Línea de trabajo

Start in the mcp package by locating ClientSession.ReadResource, readResourceCache.put, and the cache eviction logic, then find the corresponding cache tests. Run the issue's in-memory transport reproduction to confirm heap growth with zero-TTL resources. Done means zero-TTL results are not retained, expired entries are bounded without affecting the list caches, and tests cover the behavior.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Checklist
  • I searched the existing issues, and this has not been reported before.
  • This is a real problem that I ran into myself, using the latest release of the SDK.
  • I ran into it in a production system, not in a toy example, a benchmark, or an automated or AI-driven scan of the code.
  • I (a human) examined the relevant SDK code, and wrote or reviewed every line of this report. It is not unreviewed AI output.
  • This report is brief and concise, and sticks to the facts needed to understand the problem.
What happened?

On a 2026-07-28 session, ClientSession.ReadResource stores each result in the session's resource cache whatever its ttlMs, and in most cases keeps it until the session ends. A client that reads many distinct URIs, for example through a resource template, holds all of their contents in memory. In the program below, a client reads 4000 distinct 64 KiB resources from a server that sets no TTL. On a 2026-07-28 session the heap grows by about 70 MiB per 1000 reads; on a 2025-11-25 session it stays at 2 MiB.

ReadResource calls readResourceCache.put without checking ttlMs, so it also stores results with ttlMs 0, which get never returns. A Go SDK server sends 0 unless a handler or ServerOptions.SetCacheable sets a TTL. An entry is removed only when its URI is read again after it expired, or when the server sends notifications/resources/updated for it, so results with a positive ttlMs also stay after they expire if their URI is not read again. Nothing reads expired entries: a failed read returns the error rather than a stale result.

Expected: a result with ttlMs 0 is not retained (the caching specification says it "SHOULD be considered immediately stale"), and expired entries do not accumulate for the life of the session. For comparison, the Python SDK does not store results with ttlMs 0, and the Python and TypeScript SDKs bound their default in-memory caches (to 1024 entries and to 512 resources/read entries).

If you agree, I'd like to fix this myself. My approach: ReadResource stores a result only when its ttlMs is positive, and the resource cache removes its expired entries each time it has doubled in size, so the cost is amortized over the reads. The list caches stay as they are, because lookupTool relies on stale tools/list entries (#1053). I have this working locally with tests, and I'm happy to go a different way if you prefer, for example a fixed cap like the TypeScript SDK's.

AI disclosure: I found this while reading the client cache code with Claude Code, which also helped write the reproduction and this report. I ran the reproduction and reviewed the code and the report myself.

How to reproduce
package main

import (
	"context"
	"fmt"
	"log"
	"runtime"
	"strings"

	"github.com/modelcontextprotocol/go-sdk/mcp"
)

func main() {
	ctx := context.Background()

	// Every resource is 64 KiB of text. The server sets no TTL.
	body := strings.Repeat("x", 64<<10)
	server := mcp.NewServer(&mcp.Implementation{Name: "server", Version: "v0.0.1"}, nil)
	server.AddResourceTemplate(&mcp.ResourceTemplate{Name: "doc", URITemplate: "mem://docs/{id}"},
		func(_ context.Context, req *mcp.ReadResourceRequest) (*mcp.ReadResourceResult, error) {
			return &mcp.ReadResourceResult{Contents: []*mcp.ResourceContents{{URI: req.Params.URI, Text: body}}}, nil
		})

	for _, version := range []string{"2025-11-25", "2026-07-28"} {
		t1, t2 := mcp.NewInMemoryTransports()
		if _, err := server.Connect(ctx, t1, nil); err != nil {
			log.Fatal(err)
		}
		client := mcp.NewClient(&mcp.Implementation{Name: "client", Version: "v0.0.1"}, nil)
		cs, err := client.Connect(ctx, t2, &mcp.ClientSessionOptions{ProtocolVersion: version})
		if err != nil {
			log.Fatal(err)
		}
		for i := 1; i <= 4000; i++ {
			res, err := cs.ReadResource(ctx, &mcp.ReadResourceParams{URI: fmt.Sprintf("mem://docs/%d", i)})
			if err != nil {
				log.Fatal(err)
			}
			if i%1000 == 0 {
				runtime.GC()
				var m runtime.MemStats
				runtime.ReadMemStats(&m)
				fmt.Printf("%s: %d resources read (ttlMs %d), heap in use %d MiB\n",
					cs.InitializeResult().ProtocolVersion, i, res.TTLMs, m.HeapInuse>>20)
			}
		}
		cs.Close()
	}
}

// Sample output with v1.8.0 (the figures vary slightly between runs):
//
//	2025-11-25: 1000 resources read (ttlMs 0), heap in use 2 MiB
//	2025-11-25: 2000 resources read (ttlMs 0), heap in use 2 MiB
//	2025-11-25: 3000 resources read (ttlMs 0), heap in use 2 MiB
//	2025-11-25: 4000 resources read (ttlMs 0), heap in use 2 MiB
//	2026-07-28: 1000 resources read (ttlMs 0), heap in use 71 MiB
//	2026-07-28: 2000 resources read (ttlMs 0), heap in use 140 MiB
//	2026-07-28: 3000 resources read (ttlMs 0), heap in use 209 MiB
//	2026-07-28: 4000 resources read (ttlMs 0), heap in use 278 MiB
Where did you hit this?

Not in a production system; see the disclosure above.

Go MCP SDK version

v1.8.0 (also main at 0fa5e84)

Go version

go version go1.25.0 windows/amd64

Logs

No response

Lenguaje dominante
Go
Estrellas
5.3k
Forks
614
Merge medio
23 h 55 min
PR fusionados (30 d)
62

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modelcontextprotocol/go-sdk

Todos los issues de modelcontextprotocol/go-sdk

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.