Skip to content

fix(registry-servers): tag registry installs with registry+server fields#2292

Merged
reyortiz3 merged 1 commit into
mainfrom
fix/registry-install-tag-registry-source
May 27, 2026
Merged

fix(registry-servers): tag registry installs with registry+server fields#2292
reyortiz3 merged 1 commit into
mainfrom
fix/registry-install-tag-registry-source

Conversation

@reyortiz3
Copy link
Copy Markdown
Contributor

Summary

The registry-install path currently sends only req.image to the workloads API. The API then treats the request as a direct image install — req.Registry and req.Server are both empty, so workload_service.go skips resolveRegistryServer and 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 that RegistryServerName and RegistryAPIURL come back empty on the resulting RunConfig.

Policy gates that allow only "registry servers" (e.g. the enterprise non_registry_servers directive) then reject the install with errNonRegistryBlocked, even though the image is the exact one listed in the registry. Users hit this whenever the enterprise enforces non_registry_servers: false, including the canonical setup that pairs it with a registry directive.

This change tags the request so the API takes the resolveRegistryServer path end-to-end:

  • registry: 'default' — the registry name token the API understands
  • server: server.name — the canonical registry entry name (e.g. "github"), 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

User-provided fields (image, transport, target_port, etc.) still take precedence — applyRegistryDefaults only fills in missing values.

Test plan

  • Updated prepareCreateWorkloadData unit tests to assert registry: 'default' and server: <server.name> are emitted
  • Added a focused test documenting that workload name and registry entry server are deliberately distinct
  • pnpm vitest run renderer/src/features/registry-servers/lib/__tests__/orchestrate-run-registry-server.test.tsx — 17 tests pass
  • pnpm run type-check — clean
  • pnpm eslint on the two changed files — clean
  • Manual install of a registry server from the UI with non_registry_servers: false enforced — needs follow-up verification by the bug-bash reporter

🤖 Generated with Claude Code

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>
@reyortiz3 reyortiz3 merged commit 30f2b11 into main May 27, 2026
17 checks passed
@reyortiz3 reyortiz3 deleted the fix/registry-install-tag-registry-source branch May 27, 2026 20:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants