Skip to content

Stop prefixing vector_search_endpoints names#5209

Open
janniklasrose wants to merge 5 commits intomainfrom
janniklasrose/remove-vsendpoint-prefixing
Open

Stop prefixing vector_search_endpoints names#5209
janniklasrose wants to merge 5 commits intomainfrom
janniklasrose/remove-vsendpoint-prefixing

Conversation

@janniklasrose
Copy link
Copy Markdown
Contributor

@janniklasrose janniklasrose commented May 7, 2026

Changes

  • Stop applying presets.name_prefix (and the dev-mode [dev <user>] rename) to vector_search_endpoints in bundle/config/mutator/resourcemutator/apply_presets.go.
  • Add .agent/rules/name-prefix.md capturing the principle (only prefix display-name fields; never primary-key / object-id Names), scoped via globs to apply_presets.go, apply_target_mode*.go, and bundle/direct/dresources/*.go. Mirror as .cursor/rules/name-prefix.mdc.
  • Rename TestAllNonUcResourcesAreRenamedTestAppropriateResourcesAreRenamed (the carve-out list now includes a non-UC resource), and refactor the long resourceType == OR chain into a slices.Contains over a named slice hoisted to the outer loop.
  • NEXT_CHANGELOG.md entry under Bundles.

Why

The vector search endpoint name is the API primary key — it's how GET, UPDATE, and DELETE address the resource (bundle/direct/dresources/vector_search_endpoint.go: id := config.Name; recreate_on_changes for the resource doesn't list name only because there's no rename API at all, so a name change would silently drift). Prefixing it changed which remote endpoint the bundle pointed at, not just the label the user saw. The rule we want to encode is broader (display-name fields can be prefixed; identity-bearing Names cannot), but this PR only fixes the vector_search_endpoints case to keep the change focused; mlflow Models, ModelServingEndpoints, etc. have the same issue and are tracked for follow-up.

Tests

  • go test ./bundle/config/mutator/resourcemutator/ passes; TestProcessTargetModeDevelopment now asserts vs_endpoint1 (not dev_lennart_vs_endpoint1), and TestAppropriateResourcesAreRenamed includes *resources.VectorSearchEndpoint in the carve-out list and verifies the Name doesn't pick up a dev prefix.
  • Confirmed locally that re-introducing the prefix loop in apply_presets.go causes both the explicit assertion and the reflective sweep to fail with clear diffs.
  • ./task fmt, ./task checks, ./task lint, ./task test clean.

This PR was written by Claude Code.

The vector search endpoint name is the resource's primary key — it's how
GET, UPDATE, and DELETE address it. Prefixing it (via dev-mode or
presets.name_prefix) changes the resource's identity rather than just
its display name, which is the wrong semantic.

Co-authored-by: Isaac
Capture the rule the previous commit relies on: prefixing only applies
to display-name fields, never to fields the API treats as the primary
key / object id. Also point future maintainers at TestAllNonUcResourcesAreRenamed
as the enforcement mechanism.

Co-authored-by: Isaac
…enamed

The carve-out list now includes VectorSearchEndpoint, which isn't a UC
resource, so the old name no longer matches what the test does. Also
refactor the long OR chain that listed resource types to skip into a
slices.Contains over a named slice, hoisted to the outer loop so the
skip happens once per resource type instead of once per instance. Update
the agent rule that referenced the old test name.

Co-authored-by: Isaac
@janniklasrose janniklasrose requested a review from pietern May 7, 2026 13:17
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 7, 2026

Approval status: pending

/bundle/ - needs approval

Files: bundle/config/mutator/resourcemutator/apply_presets.go, bundle/config/mutator/resourcemutator/apply_target_mode_test.go
Suggested: @denik
Also eligible: @shreyas-goenka, @pietern, @andrewnester, @anton-107, @lennartkats-db

General files (require maintainer)

Files: .agent/rules/name-prefix.md, .cursor/rules/name-prefix.mdc, NEXT_CHANGELOG.md
Based on git history:

  • @simonfaltum -- recent work in ./, .agent/rules/, .cursor/rules/

Any maintainer (@andrewnester, @anton-107, @denik, @pietern, @shreyas-goenka, @simonfaltum, @renaudhartert-db) can approve all areas.
See OWNERS for ownership rules.

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.

1 participant