Part of epic [Repository detail (monolith/S05)](https://gitlab.com/groups/gitlab-org/-/epics/22453). Covers Steps 1-3 (the Client and GraphQL schema track) of the remote plan, `docs/plans/monolith/2026-08-20-repository-detail-remote.md` in the artifact-registry repo. This track gives the AR Ruby client its two delete write methods, extends the GraphQL schema so a remote repository's detail read carries the `lastDownloadedAt` artifact field, and adds the two delete mutations that call the Step 1 client methods. The client methods and the mutations are kind-neutral: AR reads the repository's own `kind` and decides whether a request permanently deletes a `hosted` artifact or evicts a `remote` cached copy, and the monolith never sees or passes that distinction. All three steps are dark behind `artifact_registry_ui` and ship no changelog (Steps 2 and 3 add schema text only, no other user-facing strings). One merge request per step, each linked back here. | Step | Merge request | | --- | --- | | 1 Client delete writes | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252683 | | 2 Remote detail read and the artifact element field | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252703 | | 3 Delete mutations | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/252723 | <details> <summary>Implementation details</summary> **Step 1: Client delete writes** (`type::feature`) - `ee/lib/artifact_registry/client.rb` (Modify): adds `bulk_delete_artifacts`, posting the whole-collection selector, and `delete_artifact`, issuing the single delete outside the retry allowlist, plus one private helper deriving the collection from the artifact format against the existing `PACKAGE_FORMATS` and `IMAGE_FORMATS`, so an unlisted format raises the name of the miss rather than composing a path with an empty segment. Both reuse the private `artifacts_path` helper. The `RETRY_OPTIONS` comment gains the DELETE half of the hazard it already states for POST. - The single-artifact delete must opt out of the retry middleware. Two mechanisms serve: narrowing `RETRY_OPTIONS[:methods]` to drop `:delete` for the whole connection, or a `retry_if` predicate excluding this one call. Narrowing is the smaller change and only costs `delete_repository` a retry it does not need, since that method already rescues its own `404`. The implementing MR picks one of the two and says which. Leaving the replay in place is not an option. - Both methods return nothing, since a `202` with no body is the whole success outcome. Neither wraps its request in `nil_on_missing`, and neither takes the `delete_repository` idempotence rescue. - `bulk_delete_artifacts(slug:, repository_name:, format:)` and `delete_artifact` take no `kind` parameter, and a repository name does not encode one, so the client cannot see or pass which semantics a request will hit. - Both methods carry doc comments recording that AR decides at request time, from the target repository's own `kind`, whether it permanently deletes a `hosted` artifact or evicts a `remote` cached copy. No behaviour change. - `ee/spec/lib/artifact_registry/client_spec.rb` (Modify). **Step 2: Remote detail read and the artifact element field** (`type::feature`) - `ee/lib/artifact_registry/maven_package.rb`, `npm_package.rb`, `image.rb` (Modify): a `last_downloaded_at` reader through the sibling `ArtifactRegistry::TimeCoercion` module. - `ee/app/graphql/types/artifact_registry/maven_package_type.rb`, `npm_package_type.rb`, `image_type.rb` (Modify): the field, `null: true` and `experiment`. It lands on the shared element types rather than remote-only ones, because AR serializes it for every kind even though a hosted repository's table does not render it. - `ee/app/assets/javascripts/packages_and_registries/artifact_registry/graphql/typedefs.graphql` (Modify): delete the three local `lastDownloadedAt` declarations that merged Step 6 added under `ArtifactRegistryImage`, `ArtifactRegistryMavenPackage`, and `ArtifactRegistryNpmPackage`. Once the schema owns the field, redeclaring it locally is a duplicate field definition in the merged SDL and fails the Apollo schema build. The `mock_artifacts.js` seeding stays, because both connections are still `@client`. - The four regenerated schema artifacts at repository root (generated, not counted against reviewable LOC): `doc/api/graphql/reference/_index.md`, both `public/-/graphql/introspection_result*.json` files, and `app/assets/javascripts/graphql_shared/possible_types.json`. - The value objects read the parsed key as it arrives, so a null `versionsCount` reaches the field as null and this step adds no coalescing. - The detail-read assertions ride here rather than in a step of their own, so the plan ships no MR without a production diff. The health-status coercion assertion is not among them: the spec amendment moved it to `monolith/S07`. - Specs: `ee/spec/lib/artifact_registry/maven_package_spec.rb`, `npm_package_spec.rb`, `image_spec.rb` (Modify); the three element type specs under `ee/spec/graphql/types/artifact_registry/` (Modify); `repository_details_type_spec.rb` (Modify, the 20-row page cap on both connections, already met by merged code and asserted rather than added); `ee/spec/requests/api/graphql/organizations/artifact_registry_repository_spec.rb` (Modify, the remote detail-read cases); `artifact_registry_repository_packages_spec.rb` and the images request spec (Modify). - No dependencies. Both external predecessors are merged: the hosted images connection [!250698](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/250698) and the typed settings read type [!251942](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251942). **Step 3: Delete mutations** (`type::feature`) - `ee/app/graphql/mutations/artifact_registry/repositories/delete_artifacts.rb` (Create): `Mutations::ArtifactRegistry::Repositories::DeleteArtifacts`, `graphql_name 'ArtifactRegistryRepositoryArtifactsDelete'`, a `name` argument, `authorize_granular_token skip_reason: :external_service_authorizes`. - `ee/app/graphql/mutations/artifact_registry/artifacts/delete.rb` (Create): `Mutations::ArtifactRegistry::Artifacts::Delete`, `graphql_name 'ArtifactRegistryArtifactDelete'`, `name` plus the artifact's `id`, the same granular-token skip. - `ee/app/graphql/ee/types/mutation_type.rb` (Modify): mount both. Both compose `Mutations::ArtifactRegistry::Base` unchanged. - Neither mutation guards on the repository's `kind`. Both call straight through to the Step 1 client methods and let AR decide, at its own `kind` check, whether the request permanently deletes a `hosted` artifact or evicts a `remote` cached copy. - Two regenerated schema artifacts at repository root, not four (generated, not counted): `doc/api/graphql/reference/_index.md` and `public/-/graphql/introspection_result.json`. - `locale/gitlab.pot` is untouched: the translated refusal string the removed guard used to raise no longer exists. - The repository mutation takes the repository as its subject and picks its route from the repository's own `format`, rather than exposing the collection as an argument (that would let a caller name a collection its repository does not have). Each payload carries the standard `errors` plus the repository the request targeted, with no count and no completion claim. - Its subject is a repository name, not "this page's repository". That is what lets the virtual plan's upstream-row affordance call this same mutation against an upstream. That plan adds no mutation, so this step's spec is where the upstream-addressed subject is asserted. - Specs: `ee/spec/graphql/mutations/artifact_registry/repositories/delete_artifacts_spec.rb` and `ee/spec/graphql/mutations/artifact_registry/artifacts/delete_spec.rb` (Create, declarative unit specs); `ee/spec/requests/api/graphql/mutations/artifact_registry/repositories/delete_artifacts_spec.rb` and `ee/spec/requests/api/graphql/mutations/artifact_registry/artifacts/delete_spec.rb` (Create, request specs). - Depends on Step 1 above. **AR's eviction handler arms are merged.** S17 Phase 6 Steps 28-30 (the per-artifact eviction arms), 31-33 (the remote bulk passes), and 35 landed on artifact-registry `main` between 2026-08-20 and 2026-08-25, and every one of them is carried in AR releases from `v1.387.0` onward. Steps 1 and 3 still assert against WebMock, which is the right level for a client unit spec, but no longer because AR has nothing to drive: what is unverified now is which AR version runs in the environment the monolith integrates against. The live view of those handler-arm rows is the Status table in the S17 Phase 6 plan (`docs/plans/2026-08-13-s17-phase6-virtual-remote-repositories.md`). </details> ## Permanent delete versus cache eviction: how AR dispatches on `kind` AR's `bulkDeletePackages` and `bulkDeleteContainerImages` routes, and their single-item counterparts `deletePackage` and `deleteContainerImage`, each serve one collection whatever the repository's kind is. AR reads `kind` off its own `repositories` row and dispatches. Nothing in the route, the request, or these mutations' arguments says which outcome will happen. That is decided inside AR, from data the monolith never asked for and does not hold. | `kind` | What the row is | What the delete removes | Recoverable | Upstream involved | AR answers | | --- | --- | --- | --- | --- | --- | | `hosted` | A published artifact someone uploaded | The artifact and everything under it: a package's versions and their files (a Maven package's package-level `maven-metadata.xml` and its checksums too, an npm package's dist-tags and cached metadata too); an image's tags, manifests, and blob links | No, other than by re-publishing | No, there is no upstream | `202`, no body | | `remote` | A cached copy of an upstream artifact | Only the cached rows. The coordinate still exists upstream | Yes, self-healing. The next pull re-caches it, which is what AR's partial unique indexes (`WHERE soft_deleted_at IS NULL`) exist to permit | No, never contacted and never changed | `202`, no body | | `virtual` | Owns no artifact rows of its own | Nothing, there is nothing to act on | Not applicable | Not applicable | `404`, and unaddressable on create anyway (`422` for `kind=virtual`) | Both live semantics answer `202` with no body, so the response alone does not tell them apart. Only the row's `kind` does. **Where the dispatch lives in AR.** There is no single polymorphic function. One shared resolver loads the row and validates both enum columns, then each handler carries its own `switch repo.Kind`, and the bulk routes carry a second switch in the worker that applies the batch. Links pinned at artifact-registry `7ec36090`: - The shared resolver every artifact route runs first: [`artifact.go#L166`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/artifact.go#L166) (`resolveArtifactRepositoryForFormat`) loads the row, `500`s an unmapped format enum, `404`s a `{format}` segment disagreeing with the stored format, then `500`s an unmapped kind enum - the fail-closed backstop the switches below treat as their second line of defense. Family wrappers: [`#L64`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/artifact.go#L64) for the maven and npm routes, [`#L52`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/artifact.go#L52) for the image routes. - `DELETE .../{format}/packages/{package_id}`: [`package_delete.go#L101`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/package_delete.go#L101) for Maven (remote arm [`mavenRemotePackageEvict`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/package_delete.go#L174)) and [`#L234`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/package_delete.go#L234) for npm (remote arm [`npmRemotePackageEvict`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/package_delete.go#L306)). - `DELETE .../{format}/images/{image_id}`: [`container_image_delete.go#L59`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/container_image_delete.go#L59), the most explicit of the set, with all four arms spelled out - hosted, remote ([`remoteContainerImageEvict`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/container_image_delete.go#L132)), virtual `404`, and a contract-violation `500` for an unmapped kind. - `POST .../{format}/packages/bulk_delete`: request-time gate at [`bulk_maven.go#L125`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/bulk_maven.go#L125) and [`bulk_packages.go#L160`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/bulk_packages.go#L160) (`npmBulkRepositoryServesKind`, which spells out why hosted resolves a child row and remote deliberately takes none); job-time at [`bulk_maven_worker.go#L525`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/bulk_maven_worker.go#L525) (`MavenBulkWorker.ops`, documented as "the worker's one kind switch, so the chain resolve and the pass cannot drift") and [`bulk_npm_worker.go#L389`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/bulk_npm_worker.go#L389) (`bulkNpmPassForKind`). - `POST .../{format}/images/bulk_delete`: request-time gate at [`bulk_container.go#L263`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/bulk_container.go#L263) (`resolveContainerBulkRepository`, which resolves a different child table per kind), job-time at [`bulk_container_worker.go#L503`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/bulk_container_worker.go#L503). - The three-way gate as an executable statement rather than as code: [`bulk_npm_routes_remote_gate_test.go`](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/7ec36090c6bc3082eadc2f38859f387b2addc867/internal/managementapi/bulk_npm_routes_remote_gate_test.go). **The bulk routes read the kind twice, and the two reads do different jobs.** The request-time gate decides only whether to admit and enqueue the job, which is what the `202` reports. The hosted-versus-remote decision that deletes or evicts happens later, inside the worker's own switch. A `202` on a bulk route therefore acknowledges a recorded job rather than a selected semantics. **Both semantics are reachable through the one mutation pair.** `ArtifactRegistryRepositoryArtifactsDelete` and `ArtifactRegistryArtifactDelete` carry no `kind` argument and no `kind` check. A caller invokes the same mutation against a `hosted` repository and against a `remote` one, and AR decides which outcome applies. A `virtual` repository has no artifact rows to delete or evict, so AR answers `404` on the delete route, which the mutation surfaces as a mutation error. **Why there is no kind guard.** There is nothing left for one to protect. AR is already the authorization boundary for the write, gating on the `delete_artifact` ability per ADR-021, and AR already fails closed on a `kind` it has no arm for (`writeContractViolation`, a `500`). `kind` is also immutable in AR (declared `readOnly`, and a `PATCH` carrying it answers `422`) and is required in AR's repository response schema, so a monolith-side guard would only duplicate checks AR already makes. An earlier revision of Step 3 named the mutations for cache eviction and then had to refuse a non-remote repository to keep the names honest, which made the hosted half of the same route unreachable. Naming them for the route removed the need for the guard. **The pair is deliberately not split by kind today.** If `monolith/S07`'s ability pre-gating later wants a different ability for evicting a re-fetchable `remote` cache than for permanently deleting a published `hosted` artifact, one mutation cannot carry both, and it gets split then. That split is nearly free while `artifact_registry_ui` stays off, so it is not a reason to pre-split now. Granular token scopes have the same shape: both mutations declare `authorize_granular_token skip_reason: :external_service_authorizes`. **AR's own API docs do not consistently describe the remote arm.** Three of the four delete operations in `api/openapi/v1.yaml` under-describe or omit it, and the fourth gets it right, which is what shows this is an oversight rather than a policy choice: 1. `bulkDeletePackages` names only npm as evicting on a `remote` repository, but remote maven is served end to end (`resolveMavenBulkScope` admits `RepositoryKindRemote`, and `MavenBulkWorker.ops` has a remote arm). 1. `deletePackage` has the same gap. Remote maven is served via `mavenPackageDelete` branching to `mavenRemotePackageEvict`. 1. `deleteContainerImage` omits the remote arm entirely, though `container_image_delete.go` implements `remoteContainerImageEvict`. 1. `bulkDeleteContainerImages` describes it correctly. Both Step 1 and Step 3 assert remote maven on both the bulk and the single-artifact path, which is correct against AR's handler code and unsupported by the contract prose, so the citation for that behaviour is the operationId plus the handler. This is an AR-side documentation gap that this track does not fix, worth raising separately against the OpenAPI spec. ## Acceptance Step 1 (client cache-eviction writes): - `bulk_delete_artifacts` posts `{"delete_all": true}` to the packages route for a `maven` and an `npm` repository and to the images route for a `docker` and an `oci` one, and treats a `202` with no body as success. - `delete_artifact` issues the package or image delete for the artifact's id on the same terms. - A bulk `503` maps to `UnavailableError` on both collections, each of which declares its own. - A single-artifact `404` raises `ApiError` carrying the status rather than resolving nil. - A connection failure on the single-artifact delete is not retried, asserted by request count. - A format outside `PACKAGE_FORMATS` and `IMAGE_FORMATS` raises `ArgumentError` before any request. No method embeds or logs a credential. Step 2 (remote detail read and the artifact element field): - On a remote repository the packages and images connections issue the same endpoints as the hosted case, which is what ADR-009's uniform artifact endpoints give them, and every element carries `lastDownloadedAt`, including null. - A remote npm element whose `versionsCount` is null resolves null rather than zero. - Both connections cap a page at 20 rows. - The detail read returns the upstream URL, the artifact cache window, the health status, and the health-checked timestamp, plus the metadata cache window for a `maven` and an `npm` repository and not for a `docker` or `oci` one. - The settings field resolves null on a hosted and on a virtual repository. Selecting every settings field returns no credential value, and a stubbed response that wrongly carried one does not reach the GraphQL response. - With the flag off, the settings field resolves null without the client being called. Step 3 (delete mutations): - `ArtifactRegistryRepositoryArtifactsDelete` issues the packages bulk-delete route for a `maven` and an `npm` repository and the images bulk-delete route for a `docker` and an `oci` one, each with the whole-collection selector, and resolves on a `202` with no body. - A `hosted` repository and a `remote` repository of the same format issue the identical request. The mutation makes no kind-based distinction and leaves the choice of permanent delete versus eviction to AR. Asserted rather than assumed, because a kind check added later would silently make one of the two callers unreachable. - A `virtual` repository reads back fine and then takes AR's `404` on the delete route, which surfaces as a mutation error. That is a different path from a repository that does not exist at all, where the read itself answers `404` and the mutation raises resource-not-available to hide its absence. - A request whose `name` argument is a repository other than the one the caller is viewing issues the route against that other repository's own name and format. - `ArtifactRegistryArtifactDelete` issues its route and resolves on a `202`, and a `404` surfaces as a mutation error rather than success. - Neither payload carries a count or a completion claim, and both return the targeted repository alongside `errors`. - A `403` on `delete_artifact` surfaces as a mutation error after the attempt, not as an existence-hiding null, because the viewer already reached the repository through a field that authorized them. - A flag-off case asserts the client is never called, because `Base` raises before any client is acquired. ## Dependencies - Step 1 has no dependencies. - Step 2 has no dependencies. Both external predecessors it needs are merged: the hosted images connection [!250698](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/250698) and the typed settings read type [!251942](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251942). - Step 3 depends on Step 1 in this issue. - `docs/specs/monolith/S05-repository-detail.md` in the artifact-registry repo needs an amendment, not yet raised. It still says the two mutations "address a **remote** repository and have no hosted counterpart", and separately holds hosted artifact deletion out of scope, both of which this design contradicts: the mutations are kind-neutral and AR dispatches on its own `kind`. - Steps 1 and 3 no longer share an AR-implementation gate: AR's eviction handler arms are merged and released, and the gate note in Implementation details above records which steps and which release. Both stay WebMock-proven, which is the right level for a client unit spec; what is unverified is the AR version deployed to the environment the monolith integrates against. - Merge-order constraint the plan states explicitly. Merged Step 6 ([!251515](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251515)) appended `lastDownloadedAt` to the two artifact-connection documents while those selections are still `@client`, and Step 2 is what puts the field on the schema. Step 2 must merge before whichever MR removes `@client` from `get_repository_packages.query.graphql` and `get_repository_images.query.graphql`, which is the hosted plan's connect step by its charter. Removing those directives first leaves a schema-bound document selecting a field the schema does not carry, which fails `graphql-verify`.