Pin BackendID through the advertising filter (tests)#5452
Merged
Conversation
Implements tests for issue #5435 (P1.2): - Assert BackendID != "" on every advertised Tool, Resource, and Prompt across the prefix, priority, and manual conflict-resolution strategies - Cover advertising-filter modes: global ExcludeAllTools, per-workload ExcludeAll, and per-workload Filter - Verify renamed/prefixed names resolve back to the backend's original name via GetBackendCapabilityName (the LookupTool/CallTool path) No production change needed: BackendID is already populated at every resolver/merge site and by the backend client. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5452 +/- ##
==========================================
- Coverage 68.85% 68.84% -0.01%
==========================================
Files 634 634
Lines 64439 64439
==========================================
- Hits 44370 44364 -6
- Misses 16789 16794 +5
- Partials 3280 3281 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
jerm-dro
approved these changes
Jun 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pin BackendID through the advertising filter (tests)
Closes #5435
Summary
RFC THV-0076 commits to keeping
BackendIDpopulated on every advertised capability as a first-class contract: it is the logical, safe-to-expose backend identifier that decorators see and thatLookupTool/CallToolrely on to route renamed/prefixed names back to their backend. Until now there was no test assertingBackendID != ""on every advertisedTool,Resource, andPrompt, so a future regression in any resolver or in the advertising filter could silently ship an emptyBackendIDand break logical-backend routing and decorator visibility. This PR adds contract tests that pin that invariant across all conflict-resolution strategies and advertising-filter modes.No production code was changed:
BackendIDis already populated at every resolver and merge site and by the backend client on resources and prompts. The investigation found no gap, so this is a test-only change that locks down the existing behavior before theVMCPcore interface and admission seam start relying on it.Changes Made
pkg/vmcp/aggregator (test-only)
advertised_backendid_test.gowith three table-driven tests:TestDefaultAggregator_AdvertisedCapabilitiesCarryBackendID— drivesAggregateCapabilitieswith a multi-backend fixture that forces afetchname conflict, then assertsBackendID != ""on every advertised tool, resource, and prompt across the prefix, priority, and manual conflict-resolution strategies. For renamed/prefixed entries it also asserts the advertised name resolves back to the backend's original capability name viaBackendTarget.GetBackendCapabilityName, and that the advertised capability'sBackendIDagrees with the routing target'sWorkloadID.TestDefaultAggregator_AdvertisingFilterPreservesBackendID— exercises the advertising-filter modes that gate the advertised set: globalExcludeAllTools, per-workloadExcludeAll, and per-workloadFilter(positive allow-list). AssertsBackendID != ""on every advertised entry, confirms the advertised tool set matches each filter mode, and verifies the routing table retains all tools with their backend identity intact (the filter affects advertising only, not routing).TestDefaultAggregator_ProcessPreQueriedCapabilitiesCarryBackendID— covers the pre-queried path across the three strategies plusExcludeAllToolsandFilter, asserting the invariant on both the full resolved set and the advertised subset, and that each advertised tool'sBackendIDmatches its routing target.Implementation Details
testing.Tplus testify (require/assert), table/subtest-driven, mirroring the existingpkg/vmcp/aggregatortest style. No Ginkgo.pkg/vmcp/mocks) and test helpers are reused; no new mock was required.shouldAdvertiseTool. For the renamed/prefixed cases the routing target is checked alongside the advertised capability to confirm the two agree on backend identity.Testing
task test.cmd/thv/app/upgrade.go.Additional Notes
VMCPcore interface,New/Serve, and admission-seam work, and is intended as a safe first landing that locks down the population contract before those pieces depend on it.