stacklok / stacklok/toolhive-core
mcpcompat: reconcile removals in per-session resource/template/prompt sync
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 2
- Forks
- 4
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 46
Description
Context
In mcpcompat/server/session.go, syncSessionTools reconciles the per-session go-sdk server against the overlay by both adding new tools and removing ones no longer present (srv.RemoveTools(removed...)). The sibling syncs for the other capability kinds are add-only:
syncSessionResourcessyncSessionResourceTemplatessyncSessionPrompts
None of them removes entries that are absent from the new overlay, even though go-sdk exposes RemoveResources / RemoveResourceTemplates / RemovePrompts.
Impact (downstream in toolhive)
toolhive's vMCP list_changed propagation (stacklok/toolhive#5965 for tools, stacklok/toolhive#5969 for resources/prompts) re-derives a session's advertised capabilities on a backend list_changed and applies them with the REPLACE-style SetSessionResources/SetSessionResourceTemplates/SetSessionPrompts. Because the underlying sync is add-only:
- Additions to a backend's resources/templates/prompts propagate to the client correctly.
- Removals do not — a resource/prompt the backend dropped stays registered on the session's go-sdk server and keeps appearing in
resources/list/resources/templates/list/prompts/listuntil the session re-initializes.
Tools do not have this problem because their sync reconciles removals.
Note: read-time access is unaffected downstream (toolhive re-derives admission per call), so this is a stale-list / name-disclosure issue, not an access bypass.
Proposed change
Mirror syncSessionTools' removal reconciliation in syncSessionResources, syncSessionResourceTemplates, and syncSessionPrompts: track the previously-synced names/URIs and call the corresponding go-sdk Remove* for entries absent from the new overlay.
Acceptance
- A REPLACE-style
SetSessionResources/SetSessionResourceTemplates/SetSessionPromptsthat omits a previously-present entry results in that entry being removed from the session's go-sdk server (and a downstreamlist_changedemitted). - After a toolhive-core release + bump, the add-only guard tests in stacklok/toolhive#5969 (
serve_session_test.go, which currently assert removed entries still appear) can be flipped to assert removal, and the NOTE comments atresyncSessionResources/resyncSessionPromptsremoved.
Reported from stacklok/toolhive#5969.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in mcpcompat/server/session.go with syncSessionTools and compare its removal reconciliation with syncSessionResources, syncSessionResourceTemplates, and syncSessionPrompts. Trace the REPLACE-style SetSessionResources, SetSessionResourceTemplates, and SetSessionPrompts paths, then verify that omitted entries are removed and list_changed is emitted; the downstream guard cases are in serve_session_test.go in stacklok/toolhive#5969.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100