Part of #1046 — **`repositories.last_updated_at` and `repositories.downloads_count` each have a writer on one format only**. Both columns get a production writer on the hosted paths the specs say move them, and those writers are reassigned from S18 to this work. The two read paths the plan does **not** reach are container remote (S16) and npm remote (S15); both stay with [#292](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/292). **References:** [repository-column-writers plan](https://gitlab.com/gitlab-org/ops/artifact-registry/-/blob/main/docs/plans/2026-09-03-repository-column-writers.md) (see "Step 5"). Line-number citations for the symbols below are pinned in the plan; this item names files and symbols only, so it does not go stale as the tree moves. **Type:** `feat` | **Depends on:** Step 1, Step 3, Step 4 | **MR:** none yet ## Dependencies, and why each is hard - **Step 1** — the S12 hosted amendment. This is a dependency for the hosted assignment it moves, not for S16: this step writes no container remote path, and Step 1 leaves S16's gate standing for that reason. - **Step 3** — the `emitSite` block and the `meterCounterEmit` column parameter, which Step 3 owns. - **Step 4** — the counter family, its drain and its write-back. This edge is a hard merge order rather than a preference: every dispatch this step adds books into the family Step 4 defines, so while Step 4 is unlanded this step would emit under a family `known()` rejects and book nothing; once Step 4 merges the same dispatches reach the buffer and drain. While Q1 (the plan's open sub-decision, which gates Step 4) is unanswered this step is transitively blocked too. ## Scope Book a `repositories.downloads_count` increment into the buffered pipeline from a delivered container blob or manifest read on the **hosted** path. No dispatch this step adds writes Postgres: the drain Step 4 lands is what turns N buffered increments into one `UPDATE`. The container remote read path is out of scope and stays with [#292](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/292). ## Files - `internal/format/oci/emit.go` (Modify) — two `emitSite` values for the read sites, added to the block Step 3 last touched. - `internal/format/oci/emit_dispatch.go` (Modify) — `meterCounterEmit` takes the column. It hard-codes `labelSizeBytes` on every outcome, and that constant's doc comment rests on the hard-coding: "an operator reading a non-zero rate here reads it as 'the emit path lost at least a byte delta', not as an inventory of the columns involved." Routing a second and third column through the same dispatcher makes that false, so the helper takes a column argument and the two new label values are added beside `labelSizeBytes`. Step 3 adds the parameter and `labelRepositoryLastUpdatedAt`, because `S3 --> S5` is a hard edge and Step 3 therefore always lands first; this step adds its own two values on top of it. The same file carries one of the six passages qualifying what this cap draws on. `counterEmitTimeout`'s doc comment says the bound applies "at the two delete sites, whose read travels inside dispatch", enumerates "all five membership reads", and computes a worker's slot ceiling as "the manifest DELETE, which emits to two scopes and reads inside dispatch: three bounds, 15s". The sites this step and Step 3 add take **no** membership read, so the enumeration of reads stays correct while the site count does not, and the ceiling has to be re-derived against whatever the new sites hold inside dispatch. - `docs/dev/storage-accounting.md` (Modify) — the read-path half, plus the site count. `## The counter sink and its seams` says "Five sites emit: blob finalize, cross-repository mount, manifest PUT, manifest DELETE and blob DELETE", and Steps 3 and 5 together take the sink to **eight** sites. The membership-read qualification is the other half: on `main` that claim sits under **In-flight caps** rather than `## Known gaps`, and `grep -c 'membership read travels inside'` returns **five** sites, not one — the `## Known gaps` table row, three further passages, and the sentence naming OCI's copy as the one of the four that also holds a pooled connection. Each makes the membership read the thing that selects which sites hold a pooled connection, so each takes the same edit. Those line numbers are pinned to `main` rather than to the plan's basis, and the Step 3 and Step 5 edits land against whatever `main` is current when each MR merges. - `internal/format/oci/blob.go` (Modify) — **four** dispatch sites, not three. `handleGet` reaches three delivered arms, `serveFull`, `serveRedirect` and `servePartial`. `handleHead` reaches none of them: it answers inline, setting and writing its status itself, so its 200 arm is a fourth site of its own. S12 counts a blob `HEAD` as a download, so a step that hooks only the three `handleGet` arms ships `HEAD` uncounted. - `internal/format/oci/manifest_read.go` (Modify) — one dispatch, in `serveRead`, which both `serveGet` and `serveHead` reach. The manifest side needs no second site for `HEAD`, which is the difference from the blob side above. **Shared seam:** the `emitSite` block in `internal/format/oci/emit.go`, owned by Step 3; this step's dependency edge is what keeps the two out of each other's way. ## Dispatch placement Step 3 says "**outside** each guard"; this step needs the equivalent to the same precision, because three of the functions it names can end in a failure status of their own. Dispatch **after the success status is written**, never at function entry: - `servePartial` re-opens the blob at a non-zero range start, and that re-open can end 416 through `writeRangeNotSatisfiable` or 500, from inside the site this step names; `blob.go` documents that path in the file itself. The dispatch goes after `w.WriteHeader(http.StatusPartialContent)`. - `serveRedirect` has the same shape through a failing `RedirectURL()`, which ends 500. The dispatch goes after `w.WriteHeader(http.StatusTemporaryRedirect)`. - `serveFull` writes its 200; the dispatch follows it. - `handleHead` sets its status and writes it; the dispatch follows the write. - `serveRead` carries 404 arms of its own and writes its success status in **two** places, one on the `HEAD` arm and one on the `GET` arm. Both need the dispatch, or it goes at a point both reach after writing. This is the one site where "one dispatch" and "one `emitSite` value" come apart, and the **Files** entry above counts the value rather than the statement. ## Acceptance A blob GET, a blob HEAD, a manifest GET, and a manifest HEAD each book one increment. One pull of an N-layer image books N+1 and drains to a single `UPDATE` of +(N+1), which is the difference from the per-read writer an earlier plan revision proposed. **A 206 partial adds one as well**, which is where container departs from Maven: S12's "does not emit" list says "Range (206) responses to blob GET: one `downloads_count += 1` per request, same as a full 200", while Maven's `bumpArchiveDownloadCount` excludes a 206. A 416, a 404, a tag listing, a referrers GET, and `GET /v2/` add nothing. A read of a container **remote** repository adds nothing either, and that is a gap rather than a rule. **Observability acceptance:** a shed or panicked emit from a read site is metered under that site's own column, so an operator can tell a lost download increment from a lost byte delta. This step adds **no** `result="ok"` arm. There is no `ok` denominator on this dispatcher today — `meterCounterEmit` is called only with the dropped and panic outcomes — and `docs/dev/storage-accounting.md` states that as a property of all three format dispatchers: "Neither of those two outcomes has an `ok` counterpart on the three format dispatchers, which emit no `result="ok"` at all, so read each as a rate on its own rather than as a share of the column's dispatches." Adding one to OCI alone would make it the odd one out and falsify that sentence, so the denominator stays a cross-format question and is not in this plan. What that costs is worth naming: `downloads_count` is unreconciled, so without a denominator the shed **rate** is not computable even in principle, and the per-column series is a rate on its own. That is a known limit of the interim metric rather than something this step fixes. ## Tests - Existing: `TestCounterSink_MembershipReadFailureRecordNamesItsSite` in `internal/format/oci/emit_test.go` is tabled over all five sites and says so in its own doc comment. Step 3 adds a sixth value and this step a seventh and eighth, so the table's rows and that completeness claim both move here. - Existing: `TestNewCounterSink_RejectsAHalfBuiltPair` pins `NewCounterSink`'s fail-fast with typed-nil rows, and the constructor fail-fasts on exactly two collaborators. Neither the guard nor that test widens here: this step adds no writer at all, because the increment travels on the `CounterEmitter` the sink already holds, and this step's **Files** list carries no datastore entry and no wiring entry. Whichever step moves that collaborator count owns the guard and the test with it. - New: one positive case for each of the four delivered read shapes, plus the 206 case as its own named subtest, because the Maven suite asserts the opposite and a reader checking one will reach for the wrong rule. The blob `HEAD` case is what fails if the step hooks only `handleGet`'s arms, so it is written before the implementation rather than after. - New: one negative case per read-path row of S12's "does not emit" list. - New: a shed on a read site meters under the read column's label rather than `size_bytes`, which is the assertion that pins the `meterCounterEmit` widening.