fix(registry-servers): tag registry installs with registry+server fields#2292
Merged
Merged
Conversation
Registry-installed workloads currently send only req.image, which makes the API treat them as direct image installs. Policy gates that allow only registry-resolved servers then reject them — even when the image is the exact one listed in the registry — because workload_service's image-name lookup misses (the registry is keyed by server name, not image URL), and RegistryServerName/RegistryAPIURL come back empty on the RunConfig. Send registry: 'default' and server: server.name so the API takes the resolveRegistryServer path. The canonical registry entry name is kept separate from the user-editable workload name, which may diverge when the user renames the workload at install time or installs the same server twice into different groups. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ChrisJBurns
approved these changes
May 27, 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.
Summary
The registry-install path currently sends only
req.imageto the workloads API. The API then treats the request as a direct image install —req.Registryandreq.Serverare both empty, soworkload_service.goskipsresolveRegistryServerand falls into the image-retriever path. That path tries to look the image up in the registry by name (provider.GetServer(serverOrImage)), which misses because the registry is keyed by server name, not by image URL. The result is thatRegistryServerNameandRegistryAPIURLcome back empty on the resultingRunConfig.Policy gates that allow only "registry servers" (e.g. the enterprise
non_registry_serversdirective) then reject the install witherrNonRegistryBlocked, even though the image is the exact one listed in the registry. Users hit this whenever the enterprise enforcesnon_registry_servers: false, including the canonical setup that pairs it with aregistrydirective.This change tags the request so the API takes the
resolveRegistryServerpath end-to-end:registry: 'default'— the registry name token the API understandsserver: server.name— the canonical registry entry name (e.g."github"), kept separate from the user-editable workloadnamewhich may diverge when the user renames the workload at install time or installs the same server twice into different groupsUser-provided fields (
image,transport,target_port, etc.) still take precedence —applyRegistryDefaultsonly fills in missing values.Test plan
prepareCreateWorkloadDataunit tests to assertregistry: 'default'andserver: <server.name>are emittednameand registry entryserverare deliberately distinctpnpm vitest run renderer/src/features/registry-servers/lib/__tests__/orchestrate-run-registry-server.test.tsx— 17 tests passpnpm run type-check— cleanpnpm eslinton the two changed files — cleannon_registry_servers: falseenforced — needs follow-up verification by the bug-bash reporter🤖 Generated with Claude Code