Session-lifecycle bookkeeping logs at info, spamming multiple log lines per request on stateless streamable HTTP
Los mantenedores suelen responder en 1 día
@anneheartrecord ya está trabajando en esto.
Desde el 28/8/2026.
- #1208 de @anneheartrecord — abierto
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 75/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- go
- Área
- backend, observability
Línea de trabajo
Busca en el Go SDK los mensajes exactos de registro del ciclo de vida de la sesión, especialmente "server connecting" y "client log level set". Ejecuta la reproducción proporcionada de Streamable HTTP sin estado y verifica que estos eventos de contabilidad ya no aparezcan en el nivel info, incluso cuando no se haya solicitado ningún nivel de registro del cliente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the bug
Found this while working on adding stateless HTTP support to the Prometheus MCP server
TL;DR: the current implementation of the new 2026-07-28 spec, and the stateless HTTP support specifically, are spamming logs with in-actionable session bookkeeping.
Summary:
The server's internal slog records for session bookkeeping (server connecting, server session connected, server session disconnected, session initialized, client log level set) all log at Info. These logs were reasonable when they were added and HTTP was stateful since they were per-session events. Now though, they're per-request:
- Stateless streamable HTTP mints a session per POST: every single request replays the connect/disconnect lifecycle.
- 2026-07-28 clients carry
_metaon every request, sosetLevelruns, loggingclient log level setonce per request, on every transport (stdio included), even when the client set no level at all (the record fires withlevel="").
The result:
A server running at a normal info log level gets four lines of pure bookkeeping for every tool call, and this is before it logs anything of its own.
To Reproduce
Steps to reproduce the behavior:
go-sdk v1.7.0, stateless streamable HTTP, one client connect plus one tools/call:
package main
import (
"context"
"fmt"
"log/slog"
"net/http"
"net/http/httptest"
"os"
"github.com/modelcontextprotocol/go-sdk/mcp"
)
func main() {
logger := slog.New(slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{
Level: slog.LevelInfo,
ReplaceAttr: func(groups []string, a slog.Attr) slog.Attr {
if a.Key == slog.TimeKey && len(groups) == 0 {
return slog.Attr{} // drop timestamps for a stable transcript
}
return a
},
}))
server := mcp.NewServer(&mcp.Implementation{Name: "probe-server", Version: "0.0.1"}, &mcp.ServerOptions{
Logger: logger,
})
mcp.AddTool(server, &mcp.Tool{Name: "echo", Description: "echo"}, func(ctx context.Context, req *mcp.CallToolRequest, input struct{}) (*mcp.CallToolResult, any, error) {
return &mcp.CallToolResult{Content: []mcp.Content{&mcp.TextContent{Text: "ok"}}}, nil, nil
})
handler := mcp.NewStreamableHTTPHandler(func(*http.Request) *mcp.Server { return server }, &mcp.StreamableHTTPOptions{
Stateless: true,
})
httpServer := httptest.NewServer(handler)
defer httpServer.Close()
ctx := context.Background()
client := mcp.NewClient(&mcp.Implementation{Name: "probe-client", Version: "0.0.1"}, nil)
session, err := client.Connect(ctx, &mcp.StreamableClientTransport{Endpoint: httpServer.URL}, nil)
if err != nil {
panic(err)
}
defer session.Close()
fmt.Println("--- one tools/call ---")
if _, err := session.CallTool(ctx, &mcp.CallToolParams{Name: "echo"}); err != nil {
panic(err)
}
fmt.Println("--- end of tools/call ---")
}
Expected behavior
To see the debug logs in my debug stream 🙃
Logs
Output from repro ^
level=INFO msg="server connecting"
level=INFO msg="server session connected" session_id=""
level=INFO msg="client log level set" level=""
level=INFO msg="server session disconnected" session_id=""
--- one tools/call ---
level=INFO msg="server connecting"
level=INFO msg="server session connected" session_id=""
level=INFO msg="client log level set" level=""
level=INFO msg="server session disconnected" session_id=""
--- end of tools/call ---
Additional context
That's four info lines per request, none of which carry information an admin can act on. At any real request rate, these events dominate the log stream. Note also client log level set firing with level="" — the client never asked for anything.
On stdio the amplification is smaller but still per-request -- the client log level set event triggers on every request it sends.
These log events were added in #501 with the reasoning "to improve debuggability", so let's demote them to debug where they belong.
- Lenguaje dominante
- Go
- Estrellas
- 5.2k
- Forks
- 568
- Merge medio
- 1 d 15 h
- PR fusionados (30 d)
- 39
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de modelcontextprotocol/go-sdk
-
Expose generic `SendNotification` on `ServerSession` for custom protocol extensionsPosiblemente ocupada @ajuijas la tomó hace 208 días. Abiertoneeds investigation
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
modelcontextprotocol/go-sdk#745 · 13 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
mcp: client returns an input_required result that has only requestState instead of retryingPosiblemente ocupada @SergeevDmitry la tomó hoy. Abierto
Dificultad 3/5 Medio día Aptitud para principiantes 62/100
modelcontextprotocol/go-sdk#1364 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 18/100
modelcontextprotocol/go-sdk#1359 ·
Los mantenedores suelen responder en 1 día
-
Streamable HTTP: a tool result that fails to marshal leaves the POST hanging (no JSON-RPC error)Abierto
Dificultad 4/5 1-2 días Aptitud para principiantes 45/100
modelcontextprotocol/go-sdk#1358 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
auth: Authorize fails against a 2025-03-26 server whose URL has a query stringPosiblemente ocupada @akshita317 la tomó hace 3 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 40/100
modelcontextprotocol/go-sdk#1347 ·
Los mantenedores suelen responder en 1 día
Todos los issues de modelcontextprotocol/go-sdk
Issues similares
-
Idle compaction monitors LIST the replica every tick when the newest destination file spans more than one TXIDPosiblemente ocupada @pishuv la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
benbjohnson/litestream#1563 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
agent-research agent-review-finding chore
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
jordansmall/spindrift#4922 ·
Los mantenedores suelen responder en 1 día
-
gcsartifact: deleting a missing version returns an errorPosiblemente ocupada @ktsoator la tomó hoy. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 2 días
-
govulncheck
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día