**Scope: hosted repositories only.** The remote figure has the same defect, but fixing it needs Artifact Registry to serve repository statistics for remote repositories first, so it moved to https://gitlab.com/gitlab-org/gitlab/-/work_items/632276, which is blocked by https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1530 (agreed in https://gitlab.com/gitlab-org/gitlab/-/work_items/628241#note_3920476043). Two pre-existing defects in the same repository sidebar stat. Neither was introduced by https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254357, but that MR is the first thing to make them reachable, because before it there was no way to delete a version and navigate back to the repository detail page. **Defect 2, the staleness, is fixed in that MR.** It turned out to be a one-line `fetchPolicy` change that needed no spec amendment, so it was fixed alongside the affordance that exposed it rather than deferred. Details and the reasoning against the eviction alternative are in the section below, kept for the record. **Defect 1, the mislabelling, is what remains open here, for hosted repositories.** The fix keeps the Packages and Images labels and makes the number correct: the hosted sidebar reads Artifact Registry's live `packages_count` (Maven, npm) or `images_count` (Docker, OCI) instead of `artifactsCount`, as discussed below. The `monolith/S05` amendment and the plan landed with https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/3000. The fix ships in three stacked MRs: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/259559 (client read), https://gitlab.com/gitlab-org/gitlab/-/merge_requests/259594 (GraphQL field), and https://gitlab.com/gitlab-org/gitlab/-/merge_requests/259614 (sidebar), and this issue closes when the last of them merges. ## Defect 1: the stat is mislabelled `repository_sidebar.vue` renders `artifactsCount` with a label chosen by format family, via `artifactsLabel`: - hosted: `Image` / `Images`, or `Package` / `Packages` - remote: `Image cached` / `Images cached`, or `Package cached` / `Packages cached` Artifact Registry does not define that counter as packages or images. Its reconciler describes it as "the version-type COUNT behind `RecomputeArtifactsCount`" (`internal/datastore/reconcile_repository.go`), and the six per-format builders are: ``` recomputeMavenVersionsStmt recomputeMavenRemoteVersionsStmt recomputeNpmVersionsStmt recomputeNpmRemoteVersionsStmt recomputeContainerManifestsStmt recomputeContainerRemoteManifestsStmt ``` So the figure counts **versions** for Maven and npm, and **manifests** for Docker and OCI. Never packages, never images. The visible result: a Maven repository holding one package at two versions renders "2 Packages" in the sidebar while the table beside it lists exactly one package row. Confirmed against a live AR service, hosted Maven repository holding `com.example:demo` at `1.0.0` and `1.1.0`: ``` SIDEBAR renders: Size=953 Downloads=0 Packages=2 TABLE renders: 1 package row (versions 1.1.0, 1.0.0) ``` The container case is wrong in the same way and is easier to miss, because a single-manifest image makes the two readings coincide. **The spec specifies the wrong label too**, which is likely how this got here, so the implementation followed it faithfully. Two passages in `docs/specs/monolith/S05-repository-detail.md` need amending: - The detail-rendered fields list: "`artifactsCount`: the buffered counter (may lag; ADR-009), rendered as the sidebar Packages or Images stat." - The Stats table, hosted and remote rows: "Packages or Images (the label following the format family)". (Superseded, kept for the record: design kept the Packages and Images labels, so the fix reads the true counts instead of relabelling.) Suggested wording, though the copy is a call for the spec amendment to settle rather than something to invent here: `Version` / `Versions` for Maven and npm, `Manifest` / `Manifests` for Docker and OCI, with the existing `cached` suffix retained on remote. The blast radius in code is small: `artifactsCount` has exactly one consumer in the UI, so this is four `n__` pairs in `artifactsLabel` plus their `gitlab.pot` entries. ## Defect 2: the value goes stale after a delete from another page (FIXED) Fixed in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254357 by setting `CACHE_AND_NETWORK` on the detail query. Verified in a GDK against a live AR service: before the change the sidebar read `Packages=2` after navigating back with **0** detail queries fired during that navigation; after it, `Packages=1` with **1** query fired. `get_repository_detail.query.graphql` is read **cache-first**, so a delete performed from any other page leaves the sidebar showing a pre-delete value for the rest of the SPA session. Only a full page reload clears it. `repository_detail.vue` runs that query with no `fetchPolicy`, and the Artifact Registry app builds its client through `createDefaultClient` without one either, so the default applies. The sibling artifact connection query immediately below it **does** set `fetchPolicies.CACHE_AND_NETWORK`, so two queries on the same page behave differently. Reproduced in a GDK against a real AR service, counting `getArtifactRegistryRepositoryDetail` requests directly: ``` detail first load: Packages=2 detailQueries=1 after SPA nav back: Packages=2 detailQueriesDuringNav=0 <- the defect after hard reload: Packages=1 ``` Delete `1.1.0` from the version list, return by breadcrumb, and the sidebar still reads `2` with zero detail queries fired during that navigation. A reload reads `1`, so the server had the correct value all along and only the Apollo cache was stale. ### What does and does not go stale `artifactsCount` is the counter that moves. Polling AR after a version delete, it went from `2` to `1` within about 14 seconds, on a delete that was **not** of the last remaining version. `sizeBytes` behaves differently and is **not** a defect, recorded here so nobody re-chases it. A version delete is a soft delete: `SoftDeleteMavenVersion` marks the version and its doc comment states that "removing the `maven_files` rows beneath the version belongs to the lifecycle purger". Since `size_bytes` is derived from the blob-bearing tables (`recomputeMavenFilesSizeStmt`), it cannot come down until that purger has run, and `lifecycle.sweep_interval` defaults to 5 minutes (`internal/config/lifecycle.go`). An initial probe polled for only 99 seconds and wrongly read the unchanged value as a stale counter; a longer probe confirmed the design, with size dropping from 506 to 152 bytes about 240 seconds after the delete. The two counters simply converge on different clocks: `artifactsCount` in roughly 14 seconds via the counter drain, `sizeBytes` in roughly four minutes via the purger. Deferred storage reclamation is the design, so Size is out of scope for this issue. `downloadsCount` is unaffected by a delete. ### Why the two obvious fixes do not apply **`refetchQueries` cannot reach it.** `artifacts_table.vue` does list `getRepositoryDetailQuery` in its refetch set, but that only works because it runs from the repository detail page, where the query is active. From the version list page the detail query is inactive and Apollo skips it, logging `Unknown query`. **Returning the repository on the mutation payload does not work either.** `S05-repository-detail.md` describes exactly that mechanism, so that "the sidebar's counters re-render from one round trip", and `ArtifactRegistryVersionDelete` does expose a `repository` field. But it is typed `RepositoryType`, GraphQL name `ArtifactRegistryRepository`, while the sidebar reads `ArtifactRegistryRepositoryDetails`. `graphql/cache_config.js` keys those as two separate normalized entries, both on `name`, and its own comment states that the detail entry "is maintained by hand" by the eviction helpers in `graphql/utils/cache_update.js`. Selecting the payload's repository would update the list entry, not the one the sidebar reads. ### Scope: not specific to one step Steps 13, 15, 16 and 18 of the monolith artifact delete surface plan add manifest, file, container tag and bulk deletes, all on the two pages where the detail query is inactive. Each inherits this, and `refetchQueries` fixes none of them. ### Open question: which fix Either an eviction of the details entry in `cache_update.js`, or switching the detail query to `CACHE_AND_NETWORK`. Worth weighing first: these counters are buffered server-side and lag regardless (ADR-009), so a fresh read is not guaranteed correct, only bounded. Cache-first staleness is unbounded on the client, which is the actual argument for doing anything at all. Both step issues (https://gitlab.com/gitlab-org/gitlab/-/work_items/627401 and https://gitlab.com/gitlab-org/gitlab/-/work_items/627402) state that `cache_update.js` is not touched by any step in the current plan, which is why this is a follow-up rather than part of the MR above. ## Suggested order Superseded by the plan merged in https://gitlab.com/gitlab-org/ops/artifact-registry/-/merge_requests/3000: the client read, then the GraphQL field, then the sidebar (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/259559, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/259594, https://gitlab.com/gitlab-org/gitlab/-/merge_requests/259614). The earlier suggestion, kept for the record: the spec amendment gates the label wording, so it goes first; the two code changes are independent of each other and both land in `repository_sidebar.vue` and `repository_detail.vue`.