[jmrplens]

resourceSubscriptions holds one request ID per URI and session, so on a 2026-07-28 session a second subscriptions/listen for a URI the session already holds replaced the first listen's ID with its own. Both listens are acknowledged with the URI, but ResourceUpdated delivered only on the second, and once the second ended the first, still open, received nothing. The three list-changed registries did the same to two listens asking for one list-changed notification.

This is the second shape from #1359, keeping the keying by session that #1275 kept:

• Each of the four registries holds the ID of every open listen of the session (per URI for resourceSubscriptions), through addListen and removeListen, and notifySubscribedSessions delivers on each with its own subscriptionId.
• A listen holds its ID once even if it names the URI twice; its teardown removes only that ID, and the session's entry with the last one.
• resources/subscribe and resources/unsubscribe keep one ID per URI and session, as before.
• SubscribeHandler and UnsubscribeHandler are still called once for each listen, as mcp: retire a listen's subscriptions only while they are its own #1360 left them, so a handler that counts them still holds the session subscribed while one listen remains.

There are no exported API changes.

TestSubscriptionsListen_EveryListenOnAURIIsNotified holds two listens open on one URI and checks, as it ends them one at a time (later first in one subtest, earlier in the other), which IDs each update reaches, the handler counts, and that the session ends unsubscribed. On main at ae26252 both subtests fail with both listens open: update delivered under subscription IDs [3], want [2 3]. TestSubscriptionsListen_EveryListenIsNotifiedOfListChanges does the same for a tools, a prompts and a resources list change, and fails the same way for each on main. TestSubscriptionsListen_URINamedTwiceIsNotifiedOnce and TestServerSubscribe_LegacyResubscribeReplacesID keep what main did for a listen naming its URI twice and for a second resources/subscribe, and each fails if its path always appends.

gofmt -l, go vet ./... and staticcheck v0.6.1 are clean, go test -race ./... passes on Go 1.26.10 and go test ./... on Go 1.25.14 and 1.26.10, and the listen and subscribe tests pass 20 runs in a row under -race.

Three existing tests are flaky under load, on main as well as with this change: in batches of 50 on Go 1.25.14 TestStreamableStateful_DiscoverDoesNotLeakSession failed 0 to 13 times on main and 0 to 8 with the change, and in batches of 160 under -race TestResourceSubscriptions_InMemory and TestResourceSubscriptions_MultipleURIs failed 1 to 25 times on main and 1 to 29 with the change. Those two call ResourceUpdated as soon as the SubscribeHandler runs, before the listen is registered.

Fixes #1489

[guglielmo-san]

what do you think about adding the same change to toolChangeSubscriptions, promptChangeSubscriptions and resourceChangeSubscriptions ?

[jmrplens]

Done in 655fc9f: the three list-changed registries now hold the ID of every open listen per session, as resourceSubscriptions does, through the same addListen and removeListen, and notifySubscribedSessions delivers on each of them. TestSubscriptionsListen_EveryListenIsNotifiedOfListChanges fails for each of the three on main and on the first commit, and passes with this one. I updated the description to match.