Skip to content

mcp: prune completed listen request IDs from the session - #1190

Merged
guglielmo-san merged 4 commits into
modelcontextprotocol:mainfrom
latent-9:fix/listen-ids-pruning
Aug 25, 2026
Merged

mcp: prune completed listen request IDs from the session#1190
guglielmo-san merged 4 commits into
modelcontextprotocol:mainfrom
latent-9:fix/listen-ids-pruning

Conversation

@latent-9

Copy link
Copy Markdown
Contributor

Problem

ServerSession tracks the request IDs of in-flight subscriptions/listen streams so Close can cancel the parked handlers and avoid the jsonrpc2 drain deadlock. The ID is appended when the listen starts, but it is never removed when the listen handler returns.

Every completed listen stream (peer cancel, unsubscribe, stream break) therefore leaves one stale entry in the session for its entire lifetime. On a long-lived session where a client repeatedly subscribes and unsubscribes, the slice grows without bound: one leaked entry per cycle.

Close calls jsonrpc2.Connection.Cancel on each recorded ID, and a stale ID is a no-op there today, but the bookkeeping is meant to hold only in-flight listens and currently never shrinks.

Change

Drop the request ID from the session's bookkeeping when the listen handler returns, matching the lifecycle of the in-flight handler that owns it.

Tests

Three tests reproduce the leak, failing on main and passing here:

  • TestListenPrunedAfterSingleCompletion
  • TestListenIDsDoNotAccumulate
  • TestListenIDsLeakViaPublicSubscribeUnsubscribe

The third exercises the leak through the public Subscribe/Unsubscribe API. go test ./mcp/ passes.

latent-9 and others added 2 commits August 22, 2026 05:44
ServerSession tracks the request IDs of in-flight subscriptions/listen
streams so Close can cancel the parked handlers and avoid the jsonrpc2
drain deadlock. The ID is appended when the listen starts but never
removed when the handler returns, so every completed listen (peer
cancel, unsubscribe, stream break) leaks one entry for the life of the
session; a client that repeatedly subscribes and unsubscribes leaks one
entry per cycle. Close's Cancel on a stale ID is a no-op today, but the
slice grows without bound.

Remove the ID when the listen handler returns.
Comment thread mcp/listenleak_test.go Outdated
Comment on lines +4 to +8
package mcp

import (
"context"
"fmt"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you add these tests to mcp_test.go? TestServerSessionCloseWithActiveListen is accessing the same listenIDs, and getSession can be deduplicated

Consolidate the tests with the existing session test infrastructure:
reuse basicClientServerConnection instead of a bespoke helper, share a
listenIDsCount accessor with TestServerSessionCloseWithActiveListen,
and drop the separate file.
@latent-9

Copy link
Copy Markdown
Contributor Author

Done. Moved the three tests into mcp_test.go next to TestServerSessionCloseWithActiveListen, reusing basicClientServerConnection for setup and a shared listenIDsCount accessor (the old test's inline lock block now uses it too), and removed listenleak_test.go.

Verified the tests still fail with the server.go fix reverted and pass with it.

@guglielmo-san
guglielmo-san merged commit 2732839 into modelcontextprotocol:main Aug 25, 2026
9 checks passed
@guglielmo-san

Copy link
Copy Markdown
Contributor

@latent-9 thank you for the contribution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants