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

Aperta
  • Qualcosa non va?
#1,526 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

  • #1527 di @Assertive-xxh — chiusa senza merge

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
74/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend, performance

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Go
Stelle
5.3k
Fork
614
Merge medio
23h 55m
PR unite (30g)
62

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/go-sdk

Tutte le issue di modelcontextprotocol/go-sdk

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.