## The defect Two columns on the `repositories` table each have a production writer on one format. - `repositories.last_updated_at` moves on an npm publish and on nothing else. A Maven publish and a container push leave it at its old value. - `repositories.downloads_count` moves on a Maven archive-class download and on nothing else. An npm download and a container pull leave it at zero. This is a different defect from the one issue [#632](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/632) tracks. That issue is about a write that the buffer sheds after the code emits it. Here the code emits nothing. No reconciliation pass repairs these values, because a repair needs a source and the write never happened. ## What ADR-007 declares ADR-007 line 170 describes both columns in the `repositories` bullet, verbatim: > Counter columns (`artifacts_count`, `downloads_count`, `size_bytes`) are maintained via [buffered/async writes](#buffered-and-asynchronous-writes) to avoid hot-row contention. `last_updated_at` tracks content changes (artifact publish/modify/delete, cache events), not downloads. The text names no format. It states one rule for the whole table. A Maven publish is a content change, and a container push is a content change. An npm download and a container pull are downloads. ADR-007 line 189 gives both columns an index for the repository landing page: > One index per sortable column for the landing page, all with `WHERE soft_deleted_at IS NULL` and a trailing `id DESC` keyset tiebreaker: `(namespace_id, artifacts_count DESC, id DESC)`, `(namespace_id, downloads_count DESC, id DESC)`, `(namespace_id, size_bytes DESC, id DESC)`, and the expression index `(namespace_id, COALESCE(last_updated_at, created_at) DESC, id DESC)`. ## Column 1 — `repositories.last_updated_at` ### The one writer `RepositoryStore.MarkRepositoryLastUpdated` at `internal/datastore/repositories.go:554` holds the real `UPDATE`. It sets `GREATEST(last_updated_at, NOW())`, so the value never moves backwards. The method is format-neutral and it takes no format argument. One production path calls it. `internal/format/npm/publish_commit.go:289-290` dispatches it through `bufferedUpdate` after the publish transaction commits. `internal/datastore/npm_publish_committer.go:257` is the wrapper between the two. A census of `MarkRepositoryLastUpdated` over `internal` and `cmd` returns no other production call site. The census finds the npm call site, which is the positive control that the pattern works. ### The Maven path builds the statement and throws it away `MavenRepositoryStore.MarkRepoLastUpdated` at `internal/datastore/maven_repositories.go:354` carries this doc comment, verbatim: > MarkRepoLastUpdated is a no-op stub. It builds the interim UPDATE setting > repositories.last_updated_at to NOW() so the swap marker below has a jet > UPDATE site to anchor, but it does not execute the statement and returns nil. > > TODO(s18-buffered-counters): execute the bump through the shared > buffered-write client once it lands; until then this stub writes nothing. The body assigns the jet `UPDATE` to `_` and returns `nil`. The call site above it is live. `internal/format/maven/upload.go:853` holds `markRepoUpdated`, and `internal/format/maven/upload.go:790` and `:799` call it. Its doc comment records the intent, verbatim: > A stub never errors, but the error is threaded so the executing path can fail the transaction once it lands. ### The container path has no writer at all `docs/specs/S12-container-oci-hosted.md:1715-1722` lists seven container write events. Each row assigns `repositories.last_updated_at = max(existing, NOW())`. The events are blob upload PUT, blob upload POST, blob mount, blob DELETE, manifest PUT, manifest DELETE, and tag DELETE. No container path calls any writer for the column. The container format ships no stub either, so there is no call site to activate. ## Column 2 — `repositories.downloads_count` ### The one writer, and the three call sites that reach it `MavenRepositoryStore.BumpRepoDownloadCount` at `internal/datastore/maven_repositories.go:316` executes a real `UPDATE`. It adds one and skips a soft-deleted repository. `internal/format/maven/download.go:230` is the only line that calls the store method. It sits inside `bumpArchiveDownloadCount` at `internal/format/maven/download.go:223`. Three production sites call that wrapper: - `internal/format/maven/download.go:288` — Maven hosted. - `internal/format/maven/download.go:383` — Maven hosted. - `internal/format/maven/remote_artifact.go:485` — Maven remote. So Maven hosted and Maven remote both move the column. npm and container move it on no path. ### npm was never specified to write it `docs/specs/S11-npm-hosted.md` contains no occurrence of `downloads_count`. `docs/specs/S15-npm-remote.md` contains no occurrence of `downloads_count`. The same file contains ten occurrences of `last_downloaded_at`, which is the positive control that the search works. `docs/specs/S16-container-remote.md:617` states the same fact from the outside: > only [S14](S14-maven-remote.md#resolutions) also counts downloads, because S15 specifies no `repositories.downloads_count` event at all. For npm this is not an unfinished write. It is an event that no npm spec defines. ### Container defines the event and assigns the writer elsewhere `docs/specs/S12-container-oci-hosted.md:1713-1714` assigns `repositories.downloads_count += 1` to a blob GET or HEAD and to a manifest GET or HEAD. `docs/specs/S12-container-oci-hosted.md:1702` then hands the column to S18. `docs/specs/S16-container-remote.md:623` is explicit for the remote half, verbatim: > The `repositories.downloads_count` increment has **no seam in S16 at all**, and that is the one place this spec departs from Maven's shape. `docs/specs/S16-container-remote.md:942` gates the acceptance criteria on the same absence: > Every `downloads_count` assertion in this section is **gated on the S18 buffered-counter pipeline** (see [Follow-ups](#follow-ups)). Until it lands there is nothing to assert: no container remote code path names the counter, so a suite asserting that a read reaches a counter seam fails a correct implementation. ## Both columns are read today The management-API repository list sorts on both columns and paginates on both. - `internal/managementapi/list.go:77` maps the `last_updated_at` sort key. - `internal/managementapi/list.go:79` maps the `downloads_count` sort key. - `internal/datastore/repositories.go:1188-1195` builds the `ORDER BY` expression for each. The `last_updated_at` arm returns `COALESCE(last_updated_at, created_at)`. - `internal/datastore/repositories.go:1311-1316` binds each column into the keyset `WHERE` bound. Both columns also reach the API as fields. `api/openapi/v1.yaml:2986-2990` describes `downloads_count` as "Buffered counter; may lag". `api/openapi/v1.yaml:3000-3004` describes `last_updated_at` as "Content changes only, not metadata edits". Neither description records that most formats never move the value. That is a second gap, and it is the contract text rather than the code. ### What the wrong value costs, stated exactly A never-written value is wrong, and it is also stable. So it mis-orders the list, and it does not break the cursor. A keyset cursor skips or repeats a row when a sort key moves between two page reads, which is the failure issue [#632](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/632) describes. This issue does not claim that failure, because a column that never moves cannot produce it. Two concrete outcomes stand on their own. A Maven repository that received a publish one minute ago sorts by its creation date. The `COALESCE` arm falls through to `created_at` for every repository that never received an npm publish. A user who sorts by recent activity sees the oldest repositories at the top of that group. Every npm and container repository holds `downloads_count = 0` forever. ADR-007 line 189 already records that these counters are low-cardinality and need the `id DESC` tiebreaker. With two formats pinned at zero, the download sort degenerates further: those rows tie at zero and order by `id` alone. An aggregate over a mixed namespace counts only its Maven rows. ## Why the two columns need different fixes Every write path in this service already opens a transaction, and every download path opens none. The two remote formats do open one, but only when the read misses and fills the cache, while the bump fires on the hit. This separates a loss that the service can prevent from a loss that only a repair can address. `repositories.last_updated_at` is emitted from a publish, so a transaction is available. Maven's call site already sits inside the upload transaction and already threads the error out, which the doc comment at `internal/format/maven/upload.go:844` states. npm's writer runs after its commit, on the pool, best-effort, which `internal/datastore/repositories.go:538-553` states. So the fix for this column can move a call that already exists into a transaction that already exists. `repositories.downloads_count` is emitted from an archive GET, and that path opens no transaction. `internal/format/maven/download.go:223` dispatches the bump as fire-and-forget, after delivery. There is no transaction to move the call into. Issue [#1026](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1026) asks for the cost of a durable download-event record, which is the only shape that reaches this column. State the two fixes separately. A single mechanism for both columns will inherit the download path's constraint for no reason. ## Why this carries `type::bug` The label was decided on evidence, and the evidence runs both ways. Both sides are recorded here, because the objection is a real one and a reader will raise it. ### The case that both absences are deliberate Three governing documents record the absence for `repositories.last_updated_at`: - `docs/specs/S10-maven-hosted.md:153` — "`repositories.last_updated_at` has no owner yet ([#442](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/442))". - `docs/specs/S10-maven-hosted.md:1667` — "S22 scopes that column out, and no spec owns its write mechanism yet". - `docs/specs/S20-a-lifecycle-closed-beta.md:589` — "`MavenRepositoryStore.BumpRepoCounters` and `MarkRepoLastUpdated` are deliberately absent". `docs/specs/S12-container-oci-hosted.md:1703` says the same for the container half. `docs/specs/S17-rest-management-api.md:1632` records one downstream effect as "Consequence, accepted". For `repositories.downloads_count`, npm defines no event, and both container specs hand the writer to S18. S18 has no spec file under `docs/specs/`. ### The case that decided it Three facts outweigh the above. First, the spec promises the write and authorizes a way to make it. `docs/specs/S10-maven-hosted.md:1199` states it as a numbered step of the upload commit: "Update `repositories.last_updated_at` to `NOW()`". `docs/specs/S10-maven-hosted.md:147` lists the column among the buffered columns the same section's interim path covers. Second, the container half is a larger instance of the same thing. `docs/specs/S12-container-oci-hosted.md:1715-1722` specifies seven container events that each move the column, and no container path calls any writer. Third, and decisively: **this project has already repaired the identical shape and typed the repair as a fix.** Issue [#971](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/971) is a jet `UPDATE` that was built and never executed, one column over. It carries `type::bug` and `severity::4`. It was repaired on 2026-08-31 by commit `2fc9c90e2`, whose subject is `fix(maven): execute the hosted last_downloaded_at access bump`. The Conventional Commits type on that commit is `fix`, not `feat`. `MavenRepositoryStore.MarkRepoLastUpdated` is that same shape. ### What the label rests on Both columns exist, both are read today, and both hold a value that two of three formats cannot influence. A counter that drifts from a correct value is a defect in behaviour that already ships, rather than functionality that is absent. One honest qualification. The `last_updated_at` half meets the narrower test as well: a spec promises the signal and the code never writes it. The `downloads_count` half does not meet that narrower test, because no governing document requires the write on npm or on OCI. It carries `type::bug` on the broader ground above — a shipped, read column holding a wrong value — and a reader who applies only the spec-promise test will reach `type::feature` for that half. ## Two corrections to the research this issue came from The split research that produced this issue named a narrower gap than the tree carries. Both corrections are recorded here rather than applied silently. 1. The research said `BumpRepoDownloadCount` is reached from `internal/format/maven/download.go:230` and from nowhere else in production. That line is the only call to the store method, and it sits in a wrapper with three callers. The third caller is `internal/format/maven/remote_artifact.go:485`, so Maven remote moves the column too. 2. The research said `repositories.last_updated_at` is missing on Maven. The container format is missing it as well, and `docs/specs/S12-container-oci-hosted.md:1715-1722` specifies seven container events that must move it. The Maven stub is visible because it exists. The container gap is invisible because nothing was written at all. ## One qualification on ADR-007's own text ADR-007 line 170 says `last_updated_at` tracks "cache events". No remote spec names the column. `docs/specs/S14-maven-remote.md`, `docs/specs/S15-npm-remote.md`, and `docs/specs/S16-container-remote.md` contain no occurrence of `last_updated_at`. The same three files carry the `last_downloaded_at` bumps, which is the positive control that the search reaches them. So the cache-event half of ADR-007's rule has no spec behind it on any format. Whoever owns this column must settle whether a cache fill is a content change before writing the code. This issue does not settle it. ## The boundary with the neighbouring issues This issue owns the missing writers. Three open issues sit next to it, and none of them owns that work. | Issue | What it owns | Why it is not this | | --- | --- | --- | | [#442](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/442) | Three S22 cleanups, including the stale `TODO` comment on the Maven stub | Its own third note asks for this issue to exist. It says the mechanism is "Not blocked, but not this issue's to do", and proposes "split it into its own `type::feature` issue with a DRI". | | [#1026](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1026) | The cost of a durable download-event record, for the shed-write repair | It is about an increment that is emitted and then lost. This issue is about an increment that is never emitted. Its own text draws that line. | | [#757](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/757) | Per-artifact download counts, which no column stores anywhere | It records the npm and container repository-level gap in one background paragraph, and it asks for the per-artifact columns. The repository-level column exists and needs a writer. The per-artifact columns do not exist. | ## Related work - [#632](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/632) — the parent question this issue was split from, and a different defect: a write that the buffer sheds. - [#1040](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1040) — the same defect shape on `container_images.last_downloaded_at` and `container_manifests.last_downloaded_at`. - [#971](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/971) — the same defect shape on Maven's `last_downloaded_at`, with a shipped interim fix. - [#442](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/442) — the `last_updated_at` cleanup issue whose third note asks for this one. - [#1026](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1026) — the sizing issue for the `downloads_count` repair path. - [#757](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/757) — per-artifact download counts, and the owner of standardizing the repository-level write onto the shared buffered client. The split is by part rather than by order: this issue adds the writers that emit nothing today, S18 decides the mechanism they and the Maven one eventually share. Neither blocks the other, because the writers can be added on the mechanism Maven already uses. - [#975](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/975) — corrects `docs/specs/S17-rest-management-api.md:93`, which still calls `BumpRepoDownloadCount` a no-op stub. - [#292](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/292) — the S18 download-tracking spec issue. ## Measurement Code and document claims: AR `origin/main` `7f766481cd1d175c9b2ba552cf1579088b889655`. Every file, line, and census in this issue was read at that sha. The three negatives carry their controls. The `MarkRepositoryLastUpdated` census over `internal` and `cmd` returns the npm call site, so it finds a caller where one exists. The `downloads_count` search over `docs/specs/S15-npm-remote.md` returns nothing, and the `last_downloaded_at` search over the same file returns ten hits. The `last_updated_at` search over the three remote specs returns nothing, and the `last_downloaded_at` search over `docs/specs/S16-container-remote.md` returns 53 hits. ADR text: the `docs/adr/` mirror at the same sha. _This is a bot message 🤖 — /smurfit_