<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=632608) </details> <!--IssueSummary end--> ## Bug Description When Artifact Registry answers `404` while the monolith resolves an organization's namespace UUID, the organization-scoped landing route and the repositories route both render not-found, so every member is told the organization has no registry. `monolith/S10` treats that `404` as a failed resolution and requires service-unavailable on both routes. ## Steps to Reproduce 1. Start from an activated organization: it has an Artifact Registry mapping row, in any status. 2. Have `GET /api/gitlab/v1/namespaces/:uuid` answer `404` for that row's UUID. S10 names the production case: a request reaching a surface that does not route it, such as an AR replica predating the endpoint mid-deploy. In a test it is `ArtifactRegistry::Client#namespace` returning `nil`, as the request specs below do. 3. As an organization member, open `/o/<organization_path>/-/artifact_registry` and `/o/<organization_path>/-/artifact_registry/<handle>/repositories`. Reproducibility: always, given an AR `404` for the UUID; it is a fixed branch in both controllers. Reproduced independently: no. Read from `gitlab-org/gitlab` `master` at `f93191f4981d`, where the request specs below pin the behavior; not run against a live stack. ## Expected Behavior Both routes answer service-unavailable, with the organization chrome still rendering. In [`monolith/S10`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/main/docs/specs/monolith/S10-activation-and-deactivation.md): - Criterion 21: "both the repositories route and the landing route answer service-unavailable rather than not-found" for a failed resolution. - `### What "not activated" means`: "A row that fails to resolve, for any reason including `404`, is an activated registry whose state is currently unknown", because the contract warns that a `404` also covers a request the surface did not route, including a replica predating the endpoint mid-deploy. - `### Resolution ordering`: the repositories route answers "Service-unavailable, not not-found, so a bookmark is not reported as a wrong URL", and the landing route answers service-unavailable as well. ## Actual Behavior Both routes render not-found (HTTP `404`). At `master` `f93191f4981d`: ```ruby # ee/app/controllers/organizations/artifact_registry_controller.rb, #handle_activation_state # A slug-less registry is a namespace that is permanently absent (an Artifact # Registry 404), so it answers not-found like any other missing resource, which is # what the repositories route already does with it. return render_404 if registry.slug.blank? # ee/app/controllers/organizations/artifact_registry_repositories_controller.rb, #ensure_resolved_slug! # An AR 404 resolves to a slug-less Registry: a permanently absent namespace, so # it answers 404 like any other missing resource. return render_404 if registry.slug.nil? ``` The behavior is deliberate and pinned by tests: - `ee/spec/requests/organizations/artifact_registry_repositories_controller_spec.rb`, context `when the namespace is absent (AR 404)`, example `answers not-found rather than service-unavailable`. - `ee/spec/requests/organizations/artifact_registry_controller_spec.rb`, context `when the namespace is absent (an Artifact Registry 404)`, which uses the `a hidden setup mount` shared example. _No correlation ID or timestamp: found by reading the code while answering a spec review, not observed in an environment._ ## Suggested Fix **This section is a hypothesis, not a finding.** Treat a slug-less registry as a failed resolution at both call sites: the landing route renders its `:unavailable` view, as it already does for a `ResolutionFailure`, and the repositories route takes its service-unavailable path. Then flip the two request specs above. Check first whether returning a `ResolutionFailure` from the resolution itself would be simpler; it probably is not, because the navigation also reads the slug-less registry and S10 wants it hidden there as not serving, which it already is. The comments' "permanently absent" reading is the one S10 rejects. ## Suggested DRI The Frontend (monolith S01–S15) workstream, whose DRI in the workstream table of `docs/roadmap/beta.md` is @rchanila. The fix lands in the monolith's Artifact Registry controllers, which that workstream owns, rather than in the AR service, whose `404` is a legitimate answer. This is a suggestion for triage, not an assignment. ## Labels to Apply - `type::bug` - `AR-Blocks::GA` — beta users are unaffected outside a window in which AR answers `404` for a mapped UUID, and the routes recover by themselves once AR answers again; nothing in the main path breaks. - `priority::2` — self-contained: two controller branches and two request specs in this codebase. - `Category:Artifact Registry` - `artifact-registry::monolith` - `backend` ## Additional Context | | | |---|---| | Environment | Code review against `gitlab-org/gitlab` `master` `f93191f4981d` | | Org slug | Not applicable: any activated organization | | Repository | Not applicable: organization-level routes | | Format | Not applicable | | Auth method | Signed-in organization member (session) | | Client and version | Not applicable: browser | | First observed (UTC) | 2026-10-07, code review | | Correlation ID | Not applicable | | Workaround | None needed after the window: both routes recover once AR answers again | Found while answering a review thread on gitlab-org/ops/artifact-registry!3177, whose amendment aligns S10's activation-page table and its Error cases row for a `404` on resolution with criterion 21. Both controllers last changed in gitlab-org/gitlab@2261048757a2 (2026-09-11). gitlab-org/gitlab#623320 tracks the landing route's other unbuilt state, the informational state for a registry that does not serve reads, in the same method.